Initialisierungswerte von Variablen

[Euklid]

Ich denke mir, dass defensive Programmierung nicht schadet. Daher vergebe ich allen Variablen in einem Initialisierungs-Abschnitt einen Wert.
Ich vermute aber, dass der Compiler genau bei den Variablen KEINEN Startwert zuweise, bei denen er "Variable doesn't seem to be initialised" (oder so) meckert.

Viele Grüße, Euklid

[hendy]

So weit ich weiß werden integerwerte nicht initialisiert, es ist nur drinn, was an der Speicherstelle steht.
Ein Kumpel hatte ein Programm, das 2 Zahlen addiert und war dann verzweifelt, warum immer 2351 zuviel rauskommt.
Tja, er hatte keine Initialisierung

[theo]

Das Verhalten des FPCs beim initialisieren ist in der Dokumentation erklärt, Kapitel 4.4

Ich glaube das ist ungenau dokumentiert. Natürlich kann eine explizite Initialisierung nicht schaden, aber bei Globalen Var. und Klassenfeldern ist es afaik nicht nötig. Bei Delphi ist es so und der FPC gibt auch keine Warnungen aus für diese Fälle.

Wenn diese Annahme nicht stimmen würde wäre FPC
A: Inkompatibel mit Delphi (Mir ist noch nie ein solches Problem beim portieren von Delphi Klassen aufgefallen)
B: Buggy im Bereich Warnungen.

[RSE]

Das Verhalten des FPCs beim initialisieren ist in der Dokumentation erklärt, Kapitel 4.4
Auszug:

Code: Alles auswählen

By default, variables in pascal are not initialized after their declaration. Any assumption that they contain 0 or any other default value is erroneous: They can contain rubbish.

Das schließt eben nicht aus, dass Variablen, wenn sie an bestimmten Stellen stehen (z.B. als Klassenvariablen, globale Variablen etc.), doch initialisiert werden. Sie werden nur nicht immer und überall initialisiert. Die Frage ist, welches sind diese bestimmten Stellen? Wo kann man sich drauf verlassen, dass sie initialisiert werden?

Ich denke mir, dass defensive Programmierung nicht schadet. Daher vergebe ich allen Variablen in einem Initialisierungs-Abschnitt einen Wert.

Damit ist man auf der sicheren Seite, hat aber bestimmt an vielen Stellen jede Menge unnötigen Code, der das Programm nur unübersichtlicher und langsamer macht (wobei die Unübersichtlichkeit heutzutage wohl gewichtiger ist).

So weit ich weiß werden integerwerte nicht initialisiert, es ist nur drinn, was an der Speicherstelle steht.

Das hat sicherlich weniger mit dem Typ der Variable (Integer oder String) als vielmehr damit zu tun, wo sie deklariert wurde (lokal, in einer Klasse oder global).

[mse]

Immer mit nil initialisiert werden die referenzgezählten ansisistring, widestring, dynamische Arrays und Interface, FPC liefert hier manchmal die falsche Warnung über nicht initialisierte Variable.
Alle Klassenfelder und globale Variablen werden mit null Bytes vorbelegt (-> false, 0, 0.0, nil...).
Nicht initialisiert werden nicht referenzgezählte lokale Variablen.

Edit:
Ebenfalls mit null initialisiert werden mit setlength() angelegte neue dynamische array items. Die Delphi Dokumentation schreibt zwar, dass lediglich arrays mit dynamischen Feldern initialisiert werden, weder Delphi 7 noch FPC machen diese Unterscheidung. Neuere Delphi Versionen kenne ich nicht. Weiss da jemand etwas genaueres?

Martin

[RSE]

Das klingt doch mal nach einer definitiven Aussage, die sich auch mit allen Beobachtungen deckt!

[knight]

Daher wäre es eben sinnvoll diese Regeln mal im FPC Reference Guide mit aufzunehmen. Aber das muss einer der Dev´s mal machen.

Dann solltest du dich an Michael van Canneyt wenden.

knight

[theo]

Das klingt doch mal nach einer definitiven Aussage,

Was? Das ist dir jetzt schon definitiv genug?
Ich möchte noch Stempel und Unterschrift mit Ort und Datum von mindestens fünf Compiler Entwicklern.

[af0815]

Für mich es eigentlich definitiv - Im Reference Guide steht drinnen, was initialisiert wird und bei allen anderen muß ich davon ausgehen, das es nicht initialisiert ist. Unabhängig davon was 'irgendwer' festgestellt hat.

Klar kann ich ja auch behaupten, bei Rot kann man über die Starsse gehen und es hat mir gestern nicht geschadet. Würdet ihr dann auch sofort bei Rot dann losrennen (Zumindest die Gene könntet ihr dann aufgrund der nartürlichen Ausese nicht mehr weitergeben SCNR ).

[khh]

sauberer ist es allemal beim Programmstart die Variablen selbst zu initialisieren.
damit erledigen sich alle entsprechenden Diskusionen


Gruss KHH

[RSE]

Klar kann ich ja auch behaupten, bei Rot kann man über die Starsse gehen und es hat mir gestern nicht geschadet. Würdet ihr dann auch sofort bei Rot dann losrennen (Zumindest die Gene könntet ihr dann aufgrund der nartürlichen Ausese nicht mehr weitergeben SCNR ).

Programmierer gehen auch blind davon aus, dass sich der Prozessor nicht verrechnet, dass die Festplatte nichts vergisst, dass das Betriebssystem korrekt arbeitet und ebenso, dass der Compiler das tut, was seine Entwickler über ihn behaupten. Letzteres wurde hier festgestellt und nun werde ich es anwenden.

[martin_frb]

Immer mit nil initialisiert werden die referenzgezählten ansisistring, widestring, dynamische Arrays und Interface, FPC liefert hier manchmal die falsche Warnung über nicht initialisierte Variable.
Alle Klassenfelder und globale Variablen werden mit null Bytes vorbelegt (-> false, 0, 0.0, nil...).
Nicht initialisiert werden nicht referenzgezählte lokale Variablen.

In der tat werden aktuell alle Referenz gezählten variable mit nil initialisiert. Das ist nötig, weil sonst bei der ersten Zuweisung an diese Variable versucht würde den alten Wert freizugeben.
IMHO ist das aber kein dokumentiertes verhalten, das heißt es kann sich in Zukunft ändern.

IIRC gab es mal eine Diskussion
function x(): String; begin end; // keine Zuweisung an Result
und irgendwo anders
a := x();

IIRc in fpc, wir a := nil, in Delphi bleibt a unverändert, oder irgendsowas. Es ist halt nicht definiert was passieren soll.

In Objekten (genau Instanzen einer Klassen Definition "a= class ... end" nicht "a = object .. end") werden tatsächlich alle variablen auf 0/nil gesetzt.
Keine Ahnung ob das dokumentiert ist, aber in einer Diskussion auf der FPC Mail liste wurde folgendes gesagt:
Klass Members werden mit 0/nil initialisiert. Dies ist zb nötig wenn im Konstruktor eine Exception auftritt. In einem solchem Fall wird automatisch der Destruktor aufgerufen. Daher müssen alle Felder mit 0/nil initialisiert sein. So weiß der Destructor das zb eine Objekt in der Variable FChildObject nicht existiert. Sonst würde FChildObject.Free zu einem Crash fuehren, da es ja auf eine zufällige Memory location zeigt.

[mse]

In der tat werden aktuell alle Referenz gezählten variable mit nil initialisiert. Das ist nötig, weil sonst bei der ersten Zuweisung an diese Variable versucht würde den alten Wert freizugeben.
IMHO ist das aber kein dokumentiertes verhalten, das heißt es kann sich in Zukunft ändern.

Dies ist nicht wahrscheinlich, da dann die erste Zuweisung und das Aufräumen am Procedureende nicht mehr funktionieren würde. Aus Prinzip und um um die Compilerwarnung zu vermeiden, mache ich jeweils trotzdem zu Procedurebeginn die nil-Zuweisung. Schön wäre es, wenn der Compiler diese "überflüssigen" Befehle entfernen würde.

IIRC gab es mal eine Diskussion
function x(): String; begin end; // keine Zuweisung an Result
und irgendwo anders
a := x();

IIRc in fpc, wir a := nil, in Delphi bleibt a unverändert, oder irgendsowas. Es ist halt nicht definiert was passieren soll.

Delphi behandelt die return Variable wie einen zusätzlichen var Parameter, die Initialisierung geschieht also irgendwo in den aufrufenden Proceduren. IIRC sind diese Dinge in der Delphi Dokumentation festgehalten.