Übergebenes nil erkennen?

[MaBuSE]

Zitat von 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)

Ich finde es schade, dass Du meine Aussagen nicht in den Kontext meiner Aussagen weiter oben in diesem Thread setzt.
(Das finde ich verwirrend )

Ich schrieb weiter oben:

Zitat von MaBuSE:

Grundsätzlich sollte ein Programmierer nie dem Compiler vertrauen und alle Variablen initialisieren.

Der Compiler gibt auch Warnungen beim Compilieren aus.
-> http://www.delphi-treff.de/tutorials...wirds-wichtig/

Versuche grundsätzlich Deine Anwendung so zu schreiben, dass keine Warnungen und Hinweise auftreten.

Ausnahme: Warnungen die Du selbst einbaust {$message warn 'Hier muss ich noch mal genau prüfen !!!'} oder {$message hint 'TODO: Quellcode muss noch kommentiert werden, damit es auch ein anderer versteht ;)'} .
Wenn Du Deinen Code immer sauber hällst, fallen solche eigenen Hinweise und Warnungen natürlich auf und animieren Dich das angemahnte auch zu tun.

Ich sagte es macht Sinn alle Variablen zu initialisieren, ich sagte nicht, man solle sie mehrfach initialisieren !!!

Delphi-Quellcode:

var
  i: Integer;
begin
  i := 0;  // <- Das ist in diesem Falle Blödsinn
  // mach was ohne auf i zuzugreifen ...
  i := FunctionX(...);  // <- das ist die initalisierung !!!
  if i = 0 then //...
  //...
end.

Lokale Variablen sind NICHT automatisch initialisiert (außer strings) !!! -> also sollte man das tun.
Bei globelen Variablen kannst Du ja folgendes (zur Dokumentation) verwenden:

Delphi-Quellcode:

var
  i: Integer = 0;

Ich empfinde das nicht als Werk eines Ahnungslosen, sondern als Dokumentation.
Abgesehen davon, dass man globale Variablen eh vermeiden sollte, muß sichergestellt werden, dass diese einen sinnvollen vordefinierten Wert haben.
Auch wenn wir wissen, dass es mit 0 initialisiert wird, sollte es für die, die es nicht wissen dokumentiert sein.

und ein var i: Integer = 0; ist kürzer als ein var i: Integer; // ist mit 0 initialisert

[Stevie]

Zitat von MaBuSE:

Ich finde es schade, dass Du meine Aussagen nicht in den Kontext meiner Aussagen weiter oben in diesem Thread setzt.
(Das finde ich verwirrend )

Es ging um das "ich schreib es lieber hin, weil ich nicht darauf vertraue, dass der Speicher initialisiert ist".

[MaBuSE]

Zitat von Stevie:

Zitat von MaBuSE:

Ich finde es schade, dass Du meine Aussagen nicht in den Kontext meiner Aussagen weiter oben in diesem Thread setzt.
(Das finde ich verwirrend )

Es ging um das "ich schreib es lieber hin, weil ich nicht darauf vertraue, dass der Speicher initialisiert ist".

Ja, aber ein Satz weiter steht doch, dass ein Programm KEINE Hinweise & Warnungen enthalten soll.
Damit ist doch klar, das Doppelt-Initialisierungen damit nicht gemeint sind.

[edit]
Wenn es dokumentiert ist, das der Compiler das so macht, ist das OK.
Wenn Du Dir nicht sicher bist, das der Compiler das so macht, initialisierte selbst.
Ein ich habe es ausprobiert und der Compiler hat es so initialisiert, finde ich nicht ok. (undokumentiertes Verhalten, kann sich ja auch in der nächsten Compiler Version ändern)
Bzw.: Bei Deinem Test einer lokalen Variable i: Integer ist zufällig 0 enthalten. Daraus kannst Du nicht schließen, dass es immer 0 ist.
Lokale Variablen werden NICHT initialisiert, das ist dokumentiert !!!
[/edit]

[DeddyH]

Werden wir jetzt nicht ein wenig zu sehr OT?

[MaBuSE]

Zitat von DeddyH:

Werden wir jetzt nicht ein wenig zu sehr OT?

Nicht direkt,
das Problem des Fragestellers ist ja, dass eine Variable, die nicht initialisiert wurde, nicht mit 0 (nil) initialisiert war.
Wenn er in der Create diese Variablen mit nil initialisiert funktioniert es.
Das hat er ja selbst geschrieben.
Wobei es sich bei seine Variablen um Objektinstanzdaten (Felder) handelt, die eigentlich mit 0 initialisiert werden sollten.
Sie es aber aus welchem Grund auch immer nicht sind. -> selbst initialisieren ist in diesem Fall also durchaus OK

In der Hilfe steht:

ms-help://embarcadero.rs_xe/rad/Variablen.html

Wenn Sie eine globale Variable nicht explizit initialisieren, wird sie vom Compiler mit 0 initialisiert. Objektinstanzdaten (Felder) werden auch mit 0 initialisiert. Auf der Wiin32-Plattform ist der Inhalt von lokalen Variablen so lange undefiniert, bis ein Wert zugewiesen wird.

[mkinzler]

Das gilt aber nicht für lokale Variablen und Feldern von Klassen (wie in diesem Fall). Hier sollte man immer initialisieren

[himitsu]

Zitat:

Wenn Sie eine globale Variable nicht explizit initialisieren, wird sie vom Compiler mit 0 initialisiert. Objektinstanzdaten (Felder) werden auch mit 0 initialisiert. Auf der Win32-Plattform ist der Inhalt von lokalen Variablen so lange undefiniert, bis ein Wert zugewiesen wird.

Globale und Objekt-Felder
Lokale

[Stevie]

Zitat von MaBuSE:

In der Hilfe steht:

ms-help://embarcadero.rs_xe/rad/Variablen.html

Wenn Sie eine globale Variable nicht explizit initialisieren, wird sie vom Compiler mit 0 initialisiert. Objektinstanzdaten (Felder) werden auch mit 0 initialisiert. Auf der Wiin32-Plattform ist der Inhalt von lokalen Variablen so lange undefiniert, bis ein Wert zugewiesen wird.

Zitat von mkinzler:

Das gilt aber nicht für lokale Variablen und Feldern von Klassen (wie in diesem Fall). Hier sollte man immer initialisieren

Erstaunlich, dass es nach mindestens einem halben Duzend wiederholtem Erwähnen immernoch Unklarheit gibt.

@Topic: Wenn es beim TE tatsächlich so sein sollte, dass ein Instanzfeld wider Erwarten und dokumentiertem Verhalten nicht nil sein sollte, wäre es mal interessant, den Source zu sehen, oder ein reproduzierbares Beispiel.