Variablen nicht NIL 64Bit

[EWeiss]

Zitat von p80286:

Ich initialisiere jede Variable, egal ob lokal oder global, weil es mir zu blöde ist mir zu merken wann durch "Zauberhand" eine Initialisierung vorgenommen wird und wann nicht.

Gruß
K-H

Jo man lernt aus Erfahrung
Aber doch seltsam das es ohne zu murren unter Win7 geht und Win10 stürzt das teil klanglos ab.

gruss

[mensch72]

Versuch der Erklärung in 4 Teilen, das es besser it nicht vom Compiler alle Variablen mit Null/Nil zu initialisieren:
1. es ist gut für Timing, den es kann bei GigaByte größen schlicht etwas dauern
2. es ist gut für die Virtualisierbarkeit, denn der VM Speichermanager rennt eben nicht gleich "bockierend" über den gesamten LokalVar Speicher, wenn in der Funktion von 6Variablen ev. nur drei real if bedingt benutzt werden
3. der Programmierer denkt nach, wenn er gezielt auch mit 0/NULL/NIL vorbelegt... eine stets bewußte Definition hilft insbesonders anderen beim Code Lesen ungemein, denn dann ist stets sofort ersichlich "der Startwert ist irgendwie wichtig" bzw. "der Startwert ist völlig egal"(heißt man muss beim Lesen im Weitern nur auf die Zuweisung achten)
4. Win7 als Vista Nachfolger wurde von MS bewußt sicher gestaltet, Win10/64 ist intern wieder höher optimiert und der WinSpeicherManager "nullt" angeforderten Speicher wirklich nur noch, wenn bei GlobalAlloc auch das ZEROMEMORY Flag mit angegeben wird... frühere WinVersionen haben stets um alle Speicherreservierungen noch ein paar Byte "Sicherheitspuffer" reserviert, sodass die ersten paar lokal Variablen eben doch stets "genullt" waren... nur war das eben ein GoodWill von MS für frühere Windowsversionen

[EWeiss]

Nun das sind wieder Beispiele bei den man als Laie voll auf die Nase fallen kann da man sich nicht sicher sein kann wie es nun korrekt sein muss.
Jeder hat eine andere Meinung und festgelegt scheint da wieder mal nichts zu sein.
Ich starte meinen Player im Vollbild Win7 alles wunderbar.. gehe nach Win10 und Crash wegen einer einzelnen Variable die man vorher nicht auf NIL gesetzt hat.

Das gleiche mit meinem OpenFileDialog.
Nun gut ist halt so.

Manchmal habe ich den Eindruck die haben da mehr verschlimmbessert.

gruss

[Medium]

Da hat niemand etwas verschlimmbessert. Wenn man lokale Variablen nicht selbst initialisiert, verlässt man sich auf sein Glück. Bei deinem 32 Bit Kompilat hattest du halt das Glück, das an der Stelle auf dem Stack zufällig die "erwartete" 0 steht. Beim 64 Bit Kompilat steht aber etwas anderes drin. Nicht initialisiert = "kann irgendwas sein, halt auch 0". Dieses Verhalten ist seit mindestens Delphi 1 so, und auch so dokumentiert. Und der Compiler warnt nicht aus Spaß an der Freud ebenfalls.
Ich selbst werte fehlende Initialisierung sogar als groben Fehler im Code. Meiner Meinung nach sollte Delphi in solchen Fällen das Kompilieren ebenso verwehren wie bei Syntaxfehlern - aber das sind Designfragen die der Kompilerbauer entscheiden darf.

[EWeiss]

Zitat:

Und der Compiler warnt nicht aus Spaß an der Freud ebenfalls.

Ja er warnt mich das diese Variable keine Verwendung findet.. also nicht benutzt wird.
Wenn es das ist was du meinst?

Du siehst also die Comunity Edition gibt keine Warnung aus D2010 hingegen schon!
Wem soll man nun glauben schenken.. Unter D2010 ist in dieser Zeile nicht mal ein Breakpoint.

Also genauer diese!

Zitat:

[DCC Hinweis] uDrawText.pas(155): H2077 Auf 'TempFont' zugewiesener Wert wird niemals benutzt

Was denn nun!
Weise ich TmpFont NIL zu spuckt der Compiler ne Warnung aus.
Tue ich es nicht dann kracht es unter Win10 64Bit.

gruss

[Schokohase]

Der Compiler hat doch absolut Recht mit der Warnung

Delphi-Quellcode:

procedure Test;
var
  SomeThing:TObject;
begin
  if Assigned(SomeThing) then
    begin
      SomeThing.Free();
      SomeThing := nil;
    end;
end;

Code:

[dcc32 Hinweis] Project1.dpr(17): H2077 Auf 'SomeThing' zugewiesener Wert wird niemals benutzt
[dcc32 Warnung] Project1.dpr(14): W1036 Variable 'SomeThing' ist möglicherweise nicht initialisiert worden

und jetzt mal so

Delphi-Quellcode:

procedure Test;
var
  SomeThing:TObject;
begin
  SomeThing := nil;
  if Assigned(SomeThing) then
    begin
      SomeThing.Free();
      SomeThing := nil;
    end;
end;

Code:

[dcc32 Hinweis] Project1.dpr(18): H2077 Auf 'SomeThing' zugewiesener Wert wird niemals benutzt

Wollen wir diese letzte Warnung auch noch wegbekommen?

Delphi-Quellcode:

procedure Test;
var
  SomeThing:TObject;
begin
  SomeThing := nil;
  if Assigned(SomeThing) then
    begin
      SomeThing.Free();
      SomeThing := nil;
    end;

  FreeAndNil( SomeThing );
end;

Bitteschön.

Jetzt die Preisfrage: Warum ist das so (und vor allem ist das unter Delphi 10.2.3 so völlig korrekt)?

Wer es weiß, darf sich ein Bonbon nehmen.

[EWeiss]

Zitat:

Jetzt die Preisfrage: Warum ist das so (und vor allem ist das unter Delphi 10.2.3 so völlig korrekt)

Die Antwort:
TempFont := Nil steht in der ersten Zeile..
Aber ihr scheint es nicht zu verstehen.

Delphi-Quellcode:

var
   TempFont: GpFont;
//..
begin
     TempFont := nil;

     if Assigned(TempFont) then
     begin
       GdipCheck(GdipDeleteFont(TempFont)); // Lösche das Font Object
       TempFont := nil;
     end;

end;

Oder kannst du sehen das irgendwo ein Try final block oder ähnliches steht was die Warnung berechtigter weise ausgibt?

Zitat:

Delphi 10.2.3 so völlig korrekt

NÖ weil sie unter Delphi2010 ausgespuckt wird und nicht unter Delphi 10.2.3..

Zitat:

Jetzt die Preisfrage:

Brauchst du eine Brille oder liest du meine Beiträge nicht!

Zitat:

Wer es weiß, darf sich ein Bonbon nehmen.

Du dir zwei wenn du meine Beiträge mal vorher lesen würdest.

Zudem TempFont wird weiter unten im Code noch verwendet habe den Teil nur nicht addiert. bzw.. zwischen TempFont := Nil und Asssign

gruss