Übergebenes nil erkennen?

[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 :gruebel:. 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 :glaskugel: 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?

[Medium]

Probier es aus. Es sollte an sich problemlos sein, das sollte es aber auch schon ohne. Daher vermute ich da Schnitzer an völlig anderen, möglicherweise sogar ganz unbeteiligten Stellen, weswegen das gesamte Projekt prima wär :)

[Stevie]

Zitat:

Zitat von solus (Beitrag 1163739)

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

Gegenfrage: Wenn ich ne Integer Variable auf 5 setze, steht dann hinterher 5 drin? :)

Antwort: ja

[solus]

Ok, gut, Danke für die Antworten.

[MaBuSE]

Zitat:

Zitat von solus (Beitrag 1163709)

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.