TStringList x64 nicht nil

[sahimba]

Es ist ganz ausdrücklich dokumentiert, dass lokale Variablen NICHT initialisiert sind.
Jedes andere von Dir beobachtete Verhalten ist als rein zufällig zu beurteilen.

[venice2]

@Uwe
Welche Delphi Version? 10.3 oder Delphi 2010!
Das ist der Unterschied.

32Bit bitte mit Delphi 2010 nicht mit 10.3

[Uwe Raabe]

Zitat:

Zitat von venice2 (Beitrag 1457203)

Welche Delphi Version? 10.3 oder Delphi 2010!
Das ist der Unterschied.

32Bit bitte mit Delphi 2010 nicht mit 10.3

Habe ich leider nicht zur Hand.

[venice2]

Zitat:

Zitat von Uwe Raabe (Beitrag 1457204)

Zitat:

Zitat von venice2 (Beitrag 1457203)

Welche Delphi Version? 10.3 oder Delphi 2010!
Das ist der Unterschied.

32Bit bitte mit Delphi 2010 nicht mit 10.3

Habe ich leider nicht zur Hand.

Mit 10.3 wird es wohl funktionieren da hier 32Bit und 64Bit mit der selben Anwendung erstellt werden.

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

Delphi-Quellcode:

procedure TestList;
var
  List: TStringList;
begin
  if List = nil then
    Writeln('List = nil')
  else
    Writeln('List <> nil');
end;

Ist immer NIL! Beim ersten Aufruf von TestList Egal wie oft ich die Anwendung starte (D2010)
Wie schon gesagt hat mit Glück nichts zu tun das ist so gegeben.
Unter D2010 scheint eine Initialisierung nicht nötig zu sein darauf wollte ich hinaus.

Zitat:

Jedes andere von Dir beobachtete Verhalten ist als rein zufällig zu beurteilen.

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

[hoika]

Hallo,
ich werfe mal die Optimierung mit rein.

mit Optimierung=nil
ohne Optimierung<>nil

getest unter D2007


und Compiler-Warnung W1036 "Variable ist möglicherweise nicht initialisiert",
die in beiden Fällen angezeigt wird.


Damit ist doch alles gesagt.

[DeddyH]

Ich finde diese Diskussion ziemlich müßig. Wenn ich nicht sicher weiß, ob in jeder Delphi-Version das erwartete Verhalten auftritt, dann sorge ich selbst für klare Verhältnisse, indem ich lokale Variablen vor dem ersten Lesezugriff grundsätzlich initialisiere. Dann ist es auch wurscht, ob Delphi XE oder Delphi Schießmichtot oder x32 oder x64.

[hoika]

Halo,
müßig ist es nicht.

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

Und man sollte schon alle Compiler-Warnungen beheben.

[DieDolly]

Es wäre interessant zu wissen was OpenFile macht.
Ist das eine Funktion von Delphi oder eine eigene?

Delphi-Quellcode:

OpenFile(FileName, List);

Egal wie man es dreht und wendet. Wenn OpenFile eine Instanz der Liste erzeugt, sollte sie sie auch wieder freigeben.
Ich vertehe gar nicht, wo man daraus so ein großes Problem machen kann.

Wenn man bei sowas einfachen einen Fehler erzeugt, ist der Code schlecht und sollte überdacht werden.

[Incocnito]

Hi Zusammen,

ist es nicht so, dass das einfach nur Speicher reserviert wird für die Variable und und dieser
Speicher (gerade nach einem Neustart) mit relativ vielen "0"ern belegt ist?
So habe ich mir sowas bisher immre erklärt.
Auch ohne Initialisierung hast du so oft nil (als Entsprechung des "leeren" Arbeitsspeichers),
aber da im reservierten RAM ja nun mal auch Bytemüll drin stehen kann,
ist das nicht sicher gestellt.
Unabhängig kann ich nur jeden Entwickler darum bitten Variablen immer zu initialisieren.
Der Compiler meckert (zumindest in allen Versionen, die ich in Erinnerung hatte)
das nicht umsonst an (in der Standardeinstellung).

LG Incocnito

[p80286]

Zitat:

Zitat von hoika (Beitrag 1457216)

Halo,
müßig ist es nicht.

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

Und man sollte schon alle Compiler-Warnungen beheben.

Müßig ist es darüber zu diskutieren unter welchen Bedingungen automatisch(!?) initialisiert wird

Zitat:

Zitat von DeddyH (Beitrag 1457215)

Wenn ich nicht sicher weiß, ob in jeder Delphi-Version das erwartete Verhalten auftritt, dann sorge ich selbst für klare Verhältnisse, indem ich lokale Variablen vor dem ersten Lesezugriff grundsätzlich initialisiere.

Und es spricht natürlich nichts gegen die Beachtung der Warnungen. Auch wenn der Programmierer es manchmal besser weiß, der Fehler sitzt viel zu oft vor der Tastatur.

Gruß
K-H