TStringList x64 nicht nil

[venice2]

List sollte eigentlich nil sein ist sie aber nicht, erst bei expliziter Zuweisung

Delphi-Quellcode:

var
  List: TstringList
begin
  
  OpenFile(FileName, List); 
end;

Kennt jemand das Problem?

[Uwe Raabe]

Zitat:

Zitat von venice2 (Beitrag 1457186)

List sollte eigentlich nil sein ist sie aber nicht, erst bei expliziter Zuweisung

Das ist so und war schon immer so. Abgesehen von reference-counted Typen werden Variablen nicht implizit initialisiert.

[venice2]

Zitat:

Zitat von Uwe Raabe (Beitrag 1457187)

Zitat:

Zitat von venice2 (Beitrag 1457186)

List sollte eigentlich nil sein ist sie aber nicht, erst bei expliziter Zuweisung

Das ist so und war schon immer so. Abgesehen von reference-counted Typen werden Variablen nicht implizit initialisiert.

In einer älteren Delphi Version ist es nicht so.
Hier ist meine Liste NIL auch ohne das ich extra

Delphi-Quellcode:

List := nil;

zuweise.

Versuch es einfach mal mit Delphi 2010 das Problem ist mir noch nie aufgefallen und auch noch nie aufgetreten.

[Dalai]

Auch ältere Delphis dürften bei derartigem Code gewarnt haben, dass die Variable (möglicherweise) nicht initialisiert ist.

Grüße
Dalai

[venice2]

Zitat:

Zitat von Dalai (Beitrag 1457189)

Auch ältere Delphis dürften gewarnt haben, dass die Variable nicht initialisiert ist.

Grüße
Dalai

Nein!
Gehe ich mit der Maus über die Zeile wird mir unter D2010 NIL angezeigt in Delphi 10.3 List()
Und Warnungen sind nicht OFF

TStringList ist doch ein Klasse und wenn diese nicht initialisiert wird sollte diese NIL sein so wie es in D2010 der Fall ist.

[Dalai]

Du hattest bisher einfach nur Glück. Lokale Variablen wurden - bis auf Ausnahmen - noch nie initialisiert. Dass (d)ein Delphi 2010 nicht warnt, ist vielleicht ein Bug, vielleicht auch eine Einstellungssache, vielleicht abhängig vom genauen Code.

Grüße
Dalai

[venice2]

Zitat:

vielleicht auch eine Einstellungssache

Ok! Habe dann wohl immer glück gehabt wobei ich schon sagte das Alle Warnungen eingeschaltet sind.

Seltsam nur das die x86 Anwendung das klaglos hinnimmt und alles läuft hingegen die x64 nicht.
Kein Beinbruch List := nil; davor zu setzen mir viel das nur auf.

Muss da jetzt nicht weiter drauf rumreiten dann ist es halt so!

[p80286]

Wenn Du jede Variable initialisierst weißt Du woran Du bist.

Gruß
K-H

[venice2]

Zitat:

Zitat von p80286 (Beitrag 1457196)

Wenn Du jede Variable initialisierst weißt Du woran Du bist.

Gruß
K-H

Eigentlich schon abgeschlossen aber Bitte Bilder sagen mehr als Worte.
Also ich denke mal das es mit Delphi nicht immer nachzuvollziehen ist was der Compiler eigentlich macht.
nil oder doch nicht nil

Mir ging es darum das es eine Nachweisbare Unstimmigkeit gibt.
Das hat mit Glück nichts zu tun es ist immer so. Da soll dann jemand durchblicken, daher auch meine Frage.

[Uwe Raabe]

Zitat:

Zitat von venice2 (Beitrag 1457199)

Das hat mit Glück nichts zu tun es ist immer so.

Ist es nicht! Lass mal dieses Programm laufen. Gerne auch mal mit DEBUG und RELEASE spielen und mal mit und ohne Debugger laufen lassen.

Delphi-Quellcode:

Program Project634;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils,
  System.Classes;

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

procedure SetList();
var
  List: TStringList;
begin
  List := TStringList.Create;
  try

  finally
    List.Free;
  end;
end;

procedure ClearList();
var
  List: TStringList;
begin
  List := nil;
end;

procedure Main();
begin
  TestList;
  SetList;
  TestList;
  ClearList;
  TestList;
end;

begin
  try
    Main;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
  Readln;
end.

[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

[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:

Zitat von venice2 (Beitrag 1457205)

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:

Zitat von venice2 (Beitrag 1457205)

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:

Zitat von venice2 (Beitrag 1457190)

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 :P Glaube ich.

[dummzeuch]

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

[venice2]

Zitat:

Zitat von dummzeuch (Beitrag 1457256)

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

Dem ist so.

Delphi-Quellcode:

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:

Zitat von Neutral General (Beitrag 1457260)

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.

[dummzeuch]

Zitat:

Zitat von Stevie (Beitrag 1457263)

Zitat:

Zitat von Neutral General (Beitrag 1457260)

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.

Das mag zwar theoretisch so sein, aber praktisch verwenden viele immernoch var statt out (insbesondere auch Tools, die Code erzeugen). Wenn der Compiler da immer rummosern würde, wäre das kontraproduktiv.

[venice2]

Zitat:

aber praktisch verwenden viele immernoch var statt out

Dann programmieren sie falsch.
@Steve hat da schon recht.

Benötige ich ein und Ausgabe dann verwende ich 'var' ansonsten den entsprechenden Parameter bei nur Ausgabe out.
Un wenn der Compiler hier keine Unterschiede macht (Warnungen betreffend) dann ist da was faul.

[himitsu]

Zitat:

Zitat von Neutral General (Beitrag 1457260)

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

Dafür ist OUT da.
Bei VAR kommt auch eine Meldung, denn die Variable muß initialisiert sein, damit der Code in der Funktion prüfen kann, ob dort etwas übergeben wurde. (if not assigned then create)
Bei OUT geht der Compiler davon aus, dass nichts übergeben wird und somit muß die Variable auch nicht initiaisiert sein.

[venice2]

Zitat:

Bei VAR kommt auch eine Meldung

Kommt nicht es sei denn dein Delphi hat einen anderen Compiler oder ich bin zu dumm den korrekt einzustellen.
Ich wiederhole mich ungern aber meine Warnungen sind eingeschaltet und ich behandle sie alle.

(EDIT)
Hätte ich also eine Warnung bekommen wäre diese behandelt worden und die Anwendung wäre nicht abgestürzt.
Solche Probleme sind im Nachhinein sehr schwer zu finden.
Unter den Voraussetzung hätte ich meine Frage hier gar nicht erst reinstellen müssen.

[himitsu]

Dann müssen die das aber irgendwann kaputt gemacht haben und sollten den Bug schnell wieder reparieren.

[Luckie]

Die Diskussion über varParameter hat jetzt aber nichts mehr mit der ursprünglichen Fragestellung zu tun! Bitte führt sie an anderer Stelle weiter, wenn ihr weiter darüber diskutieren wollt.

[himitsu]

Nja, es geht darum dass Variablen initialisiert werden müssen und dass der Compilier dort (eigentlich) auch Warnungen wirft (was aber auch nicht immer funktioniert), wenn man es vergessen hat.

[Dalai]

Zitat:

Zitat von venice2 (Beitrag 1457261)

Sie wird erst gefüllt wenn OpenFile von außerhalb meiner Klasse aufgerufen wird.

Ein Befüllen einer TStringList ist auch möglich, wenn diese als

Delphi-Quellcode:

const

an eine Funktion übergeben wird. Nur ein Zuweisen einer neuen Instanz benötigt

Delphi-Quellcode:

var

(oder

Delphi-Quellcode:

out

). Eine Variable auf eine TStringList hält doch nur einen Pointer auf einen Speicherbereich, was die Veränderung des Speicherbereichs (=Inhalte der TStringList) aber nicht verhindert.

Kurz gesagt: Überleg dir ganz genau, ob du das

Delphi-Quellcode:

var

wirklich brauchst.

Grüße
Dalai

[Uwe Raabe]

Das worked offenbar as expected: Missing compiler warnings for uninitialized variables

Zitat:

Not the ideal scenario, but not going to change this

[dummzeuch]

Zitat:

Zitat von himitsu (Beitrag 1457273)

Dann müssen die das aber irgendwann kaputt gemacht haben und sollten den Bug schnell wieder reparieren.

Der Compiler hat bei var noch nie eine Warnung ausgespuckt. Sie haben ihn also nicht kaputt gemacht, er war es höchstens schon immer (seit Turbo Pascal).

out wurde erst mit Delphi 3 eingeführt. Vorher haben alle var verwenden müssen. Deshalb gibt es auch so viel Code, der var anstelle von out verwendet (never touch working code). Hätten sie bei der Einführung von out eine neue Warning eingeführt, wären sie von den Delphi-Programmierern gesteinigt worden.

Vielleicht wäre es aber tatsächlich an der Zeit, zumindest optional eine solche Warning einzuführen. Wir haben schließlich 2020 und nicht mehr 1997.