TStringList x64 nicht nil

[haentschman]

Zitat:

Und es spricht natürlich nichts gegen die Beachtung der Warnungen

[OT]
Als ich das Projekt übernommen hatte, hatte ich über 600 Warungen / Hinweise. Da findest du die Wichtigen nicht! 2 Wochen, incl. Umbau, hat es gedauert, das auf 0 Fehler zu kürzen. Da kann man auch solche Warnungen erkennen.
[/OT]

[Uwe Raabe]

Zitat von venice2:

Und ja ich werde bei 64Bit in der Zukunft darauf achten alles vorher zu initialisieren.

Ich würde das an deiner Stelle gar nicht so einschränken. Variablen sollten vor der Benutzung immer initialisiert werden. Es gibt Fälle, bei denen der Compiler das macht, aber das ist für viele nicht immer klar erkennbar. Es schadet auch nicht, wenn man diese Fälle auch selbst übernimmt.

Zitat von venice2:

Dann teste den Anhang. Wenn du bei 1000 Aufrufen ein anderes Ergebnis bekommst sage bescheid.

Ich habe dein Testprogramm nun in einer VM mit D2010 laufen lassen. Es hat gar keine 1000 Aufrufe gebraucht:

[Neutral General]

Die Sache ist die: lokale Variablen sind nur Speicherbereiche auf dem Stack. Der mag vielleicht bei Programmstart mit 0en initialisiert sein, aber sobald mal ein bisschen Code gelaufen ist liegen an den Stack-Adressen alle möglichen Werte wie alte Rücksprungadressen oder Parameter für Funktionsaufrufe. Wenn eine lokale Variable deklariert wird, wird ihr bloß ein entsprechend großer Bereich auf dem grad verfügbaren Stack zugewiesen. Wenn der Bereich zuvor schon genutzt wurde, dann steht an dieser Speicherstelle mit großer Wahrscheinlichkeit keine 0.

Das kann also grundsätzlich noch nie geklappt haben (außer durch Glück oder vllt. beim Debuggen).

[himitsu]

Zitat von venice2:

Nein!

Doch, gewarnt wurde da schon immer, wenn du sowas nicht initialisierst,

außer bei globalen Variablen oder als Objektfelder, aber die sind auch in x64 immer mit 0 initialisiert.

[DieDolly]

Zitat:

Doch, gewarnt wurde da schon immer, wenn du sowas nicht initialisierst,

Oder wenn man Warnungen abgeschaltet hat Glaube ich.

[dummzeuch]

Wie ist denn OpenFile deklariert? Ist List evtl. ein var Parameter? Wenn ja, warnt der Compiler nicht.

[venice2]

Zitat von dummzeuch:

Wie ist denn OpenFile deklariert? Ist List evtl. ein var Parameter? Wenn ja, warnt der Compiler nicht.

Dem ist so.
OpenFile(ip_FileName: AnsiString; var List: TStringList)

[Neutral General]

Dann gibts natürlich keine Warnung, weil der Compiler davon ausgeht, dass die Liste ggf. in der Funktion angelegt und über den Var-Parameter zurückgegeben wird.
Falls du die Liste in der Funktion nicht erstellst oder komplett neu zuweist ist der var Parameter falsch und sollte weg.

[venice2]

Zitat:

Falls du die Liste in der Funktion nicht erstellst oder komplett neu zuweist ist der var Parameter falsch und sollte weg.

Danke für den Hinweis aber er ist nicht falsch und kann auch nicht weg.

Es hat schon einen Grund warum beim initialisieren meiner Klasse die Liste NIL sein muss.
Sie wird erst gefüllt wenn OpenFile von außerhalb meiner Klasse aufgerufen wird.

Darum ging es aber auch nicht sondern um die Frage warum in x64 nicht NIL und unter x86 = NIL ohne List zu initialisieren.

Denke die korrekte Antwort kommt von @hoika. Damit ist die Frage für mich beantwortet.

Zitat:

mit Optimierung=nil
ohne Optimierung<>nil

Zitat:

@hoika Halo,
müßig ist es nicht.

Es lesen ja auch Anfänger mit (hoffentlich).

Und man sollte schon alle Compiler-Warnungen beheben.

Richtig!
Nur in meinem Fall gibt es keine Warnung sagte ich schon. Warum wurde auch schon geklärt.

[Stevie]

Zitat von Neutral General:

Dann gibts natürlich keine Warnung, weil der Compiler davon ausgeht, dass die Liste ggf. in der Funktion angelegt und über den Var-Parameter zurückgegeben wird.

Und das Verhalten ist auch schlichtweg falsch - denn var ist ein in/out Parameter - das sollte für eine Warnung vom Compiler sorgen. Nur bei out darf semantisch egal sein, was vorher drin steht.