Übergebenes nil erkennen?

[solus]

Whoa, was sich doch nicht alles aus einer einfachen Frage ergibt.

Der konkrete Anwendungsfall (über das Minimalbeispiel hinaus) war die Erstellung eines Binären Suchbaums (AVL).

type TKnoten=class(TObject)

rechts,links : TKnoten
...
end;

function hoehe(knoten:TKnoten) : integer;
begin
if knoten =nil then result:=0
else ...
end;

function balance(knoten : TKnoten) : integer;
begin
result:=hoehe(links)-hoehe(rechts);
end;

Das Warnsystem hat bei mir daher nicht angeschlagen (rechts,links werden ja benutzt) und Objektfelder werden anscheinend wie lokale Variablen behandelt.

Mittels

constructor create; override;
begin
inherited create;
rechts:=nil;
links:=nil;
end;

sollte ich dann aber sicher sein, oder?

Einzige Alternative wäre halt ne blöde Fallunterscheidung...

[Medium]

Hast du bei deinen Methoden einfach nur das "TKnoten." vergessen, oder sind das wirklich nur Funktionen/Prozeduren (gegenüber Methoden (welche immer zu einer Klasse gehören))? In dem Fall würden die Felder nicht wie lokale Variablen behandelt, sondern Delphi setzt innerhalb von Methoden der Klasse vor die eigenen Felder implizit eine "self." Referenz. Es sind aber nach wie vor Felder, keine lokalen Variablen. Es muss daher, dem Beispiel hier nach, auch ohne explizites nil im Konstruktor gehen (welche man übrigend nicht überläd).

Ich vermute schon fast einen Klassiker hier:

Delphi-Quellcode:

var
  k: TKnoten;
begin
  // Erzeugung vergessen
  k.TuWas();
  .
  .
end;

Also Fehler in der Verwendung, nicht der Klasse selbst. Gegebenenfalls kann das auch innerhalb einer Methode von TKnoten passieren, wenn es dort solche gibt, die neue Knoten einfügen und diese selbst erzeugen müssten (also keinen fertigen neuen TKnoten als Parameter von aussen mit bekommen).

[solus]

Es geht doch gerade darum, dass nicht initialisiert wird.

Ich habe einen Baum und will die Höhe des rechten Unterbaums der Wurzel wissen und rufe daher

hoehe(wurzel.rechts) auf (jaja unsauber, rechts sollt private sein)

dummerweise ist der rechte Unterbaum leer. Da ich aber im constructor wurzel.rechts:=nil gesetzt habe, rufe ich effektiv hoehe(nil) auf und bekomme 0 zurück.

Geht das?

(PS: Ich hab den Konstruktor dich nicht überladen, sondern überschrieben, oder?)

[Medium]

Ups, ja hast du. Tut man aber genausowenig

Ist der rechte Teilbaum denn gewollt leer, oder ist das Teil des Problems?

[solus]

Darum geht es doch!

In einem Baum kann doch der rechte Unterbaum einfach leer sein. Der Pointer ist trotzdem da, da dort ja ein Unterbaum sein könnte.

[Medium]

Der müsste aber leider wirklich von Anfang an nil sein, ohne dass man es selbst im Konstruktor setzt . Kannst du evtl. ein Testprojekt hier anhängen, dass das illustriert? Weil mir kam es in all den Jahren nicht vor, dass Delphi (in diversen Versionen) da einfach was vergessen hätte. Kann ich dann zwar erst morgen durch Delphi jagen, aber das wäre doch sehr hilfreich jetzt.

[Stevie]

Ich würde auch empfehlen, wenn schon, dann korrekten Source zu posten, und keinen erdachten, der eh nicht funktioniert, so wie dieser hier.

Delphi-Quellcode:

function balance(knoten : TKnoten) : integer;
begin
result:=hoehe(links)-hoehe(rechts);
end;

Sonst können wir nur unsere befragen, und da ist grad die Batterie leer

[solus]

Ich kann morgen das mal hochladen.

Da ich aber eine Klausur schreibe, ist folgendes momentan für mich wichtiger:

Wenn ich es (evtl. unnötigerweise) setze, wird es sicher als nil erkannt?

[MaBuSE]

Zitat von solus:

Delphi-Quellcode:

constructor TKnoten.Create; override;
begin
  inherited Create;
  rechts:=nil;
  links:=nil;
end;

Sollte ich dann aber sicher sein, oder?

Ich würde es genau so machen.
Das meinte ich eigentlich mit "Trau nicht dem Compiler".
In dem Fall, dass Du Dir nicht sicher bist, ob die Variablen "richtig" initialisiert werden, solltest Du sie einfach selbst initialisieren.
Dann bist Du auf der sicheren Seite.

Ich empfinde es auch als "Dokumentation" gut, wenn Variablen initialisert werden, und man sich nicht darauf verlässt, das es der Compiler schon richtig initalisieren wird. Das zeigt dass Du bewusst diesen Wert (in Deinem Fall nil) zugewiesen haben möchtest.

Das ist wie beim Rechnen. Auch wenn eindeutig geregelt ist, macht es manchmal Sinn eine Klammer zu setzen.
2*2+2*2 = (2*2)+(2*2)
Wenn jemand in den Taschenrechner 2*2+2*2 eingibt macht er (2*2+2)*2
Das sollte jeder wissen, aber mit Klammern ist es eindeutig zu sehen.

Nichts anderes wollte ich oben mit meinem Beitrag ausdrücken.

[Stevie]

Zitat von MaBuSE:

Ich empfinde es auch als "Dokumentation" gut, wenn Variablen initialisert werden, und man sich nicht darauf verlässt, das es der Compiler schon richtig initalisieren wird. Das zeigt dass Du bewusst diesen Wert (in Deinem Fall nil) zugewiesen haben möchtest.

Dem muss ich widersprechen.

Für mich persönlich ist es sehr viel verwirrender, wenn ich sowas im Sourcecode sehe. Dann frag ich mich, ob hier entweder ein ahnungsloser am Werke war, oder ob es irgendein Problem gab, weswegen das gemacht wurde.

Genauso initialisier ich eine Variable nur dann, wenn deren Wert irgendwo benutzt wird, bevor ihr ein Ergebnis einer Operation zugewiesen wird. (Stichwort H2077 Value assigned to <variable> never used)