Variablen nicht NIL 64Bit

[EWeiss]

Ja bestimmt nerve ich schon mit dem Kram
Folgendes verhalten.

Delphi-Quellcode:

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

end;

Mit D2010 und 32Bit Anwendung habe ich hier kein Problem.
Bei 64Bit kracht es weil beim Ausführen der Funktion TempFont anscheinend nicht NIL ist.
Sie wird nicht mit NIL initialisiert sondern irgendeinen imaginären wert.
Das gleiche Problem habe ich auch schon bei anderen Funktionen bemerkt.

Warum ist das so?

Es funktioniert unter 64Bit nur dann wenn ich sie selbst initialisiere.

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;

In D2010 bekomme ich dann aber eine Warnung.. Variable wird nicht verwendet.
Sehr seltsam dieses Verhalten.
Man sollte wirklich mal einen Thread erstelle Wie Migriert man richtig zu 64Bit
Die Fehler die ich bisher schon gefunden habe sind wirklich kurios bis weilen.

Seltsamerweise tritt dieser Fehler aber nur unter Win10 auf das kommt noch dazu.

gruss

[arnof]

also; ich habe erst gestern darüber diskutiert, das Variablen nicht nil sind, wenn man Sie definiert und ich sicher sein muss das Sie nil sind.

Fazit:

Global Variablen sind das; hier kann man aber auch angeben:


var
TempFont: GpFont=nil;


Das geht bei localen Variablen nicht und diese sind auch nicht nil bei der Definition.

Möglich das es einen Compiler Schalter gibt, den Du vieleicht im alten Delphi angeschaltet hast; ich weiss das aber nicht ob es den gibt.

Also ich definiere Variablen Inhalte, wenn ich einen definierten Wert brauche.

[Ghostwalker]

Das hat noch nicht mal was mit 32-Bit/64-Bit zu tun. Generel haben Variablen erstmal einen undefinierten Inhalt, bis sie initialisiert werden (egal ob das nun Zeiger, Methodenzeiger oder sonstwas sind).

Das ganze ist mir schon mit 32-Bit passiert und ich geh mal davon aus das das mit 64-Bit nicht anders ist.

[EWeiss]

Zitat von Ghostwalker:

Das hat noch nicht mal was mit 32-Bit/64-Bit zu tun. Generel haben Variablen erstmal einen undefinierten Inhalt, bis sie initialisiert werden (egal ob das nun Zeiger, Methodenzeiger oder sonstwas sind).

Das ganze ist mir schon mit 32-Bit passiert und ich geh mal davon aus das das mit 64-Bit nicht anders ist.

Das Problem ist mit 32Bit\64Bit und D2010 (Win7) stürzt die Anwendung nicht ab.
In 64Bit unter Win10 stürzt sie ab bei gleichen Code..

Nun gut warum weiter aufregen ich werde sie selbst entsprechend definieren und gut ist..
Muss die Warnung von D2010 halt ignorieren.

Danke.

[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

[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