USE_BEFORE_DEF kann nicht ausgeschaltet werden ?

[charly52]

Hi all,

ich möchte in folgendem Code

Delphi-Quellcode:

begin
  IF Gesperrt0(aCol,-1) THEN
  BEGIN
    aFarbe:= DG0_AbtlNamen.Canvas.Brush.Color;
  END;


  Dann was tun
  

{$WARN USE_BEFORE_DEF OFF}
  IF Gesperrt0(aCol,-1) THEN DG0_AbtlNamen.Canvas.Brush.Color:= aFarbe;
{$WARN USE_BEFORE_DEF ON}
end;

die Warnung

[dcc32 Warning] xxxxxx.PAS(281): W1036 Variable 'aFarbe' might not have been initialized

loswerden. Hier in einem Tutorial habe ich gefunden, daß USE_BEFORE_DEF OFF genau dafür zuständig sei.
Scheint aber nicht so zu sein, da ich die Warnungen immer noch bekomme.
Ich finde auch keinen anderen Eintrag in der Liste der Warnungen.

{$WARN USE_BEFORE_DEF ON}
Warnung: Variable '<Element>' ist möglicherweise nicht initialisiert worden
Diese Warnung wird angezeigt, wenn einer Variablen nicht in jedem Codepfad, der zu der Stelle führt, an der sie verwendet wird, ein Wert zugewiesen wird.


Danke Charly

[himitsu]

Warum nicht den eigentlichen Fehler beheben?

Sorge dafür, dass der Variable auch bei ELSE etwas zugewiesen ist und Problem gelöst. (oder vor dem ersten IF)



PS: TBrushRecall
https://www.delphipraxis.net/1288015-post5.html

[add]

Delphi-Quellcode:

begin
  Recall := nil;
  IF Gesperrt0(aCol,-1) THEN
  BEGIN
    Recall := TBrushRecal.Create(DG0_AbtlNamen.Canvas.Brush);
  END;


  Dann was tun
  

  Recall.Free;  // unnötig nochmal Gesperrt0 auszuführen, weil intern über Assigned(Recall), im Free, die vorherrige Ausführung oder Nicht-Ausführung erkannt wird
end;

[TurboMagic]

Hallo,

mir scheint, du willst die Warnung unterdrücken.
Das ist aber in vielen Fällen nicht der richtige Ansatz!

Schau dir nochmal deinen Code an und überlegt, ob der Compiler nicht doch recht damit hat,
dass es Fälle gibt, in denen du dieser Farbvariablen nichts zuweist.

Welche Farbe soll die dann haben?

Grüße
TurboMagic

[Sinspin]

Ich frage mich ehrlich warum es so einen Unsinn überhaupt gibt!
Warum soll man dabei unterstützt werden unsauber zu programmieren?

Wo ist im Beispiel eigentlich das Problem die Variable mit einer sinnvollen Farbe zu initialiseren?

[himitsu]

Hier ist die Meldung berechtig.

Ich habe kenne aber auch zwei Fälle, wo diese Meldung kommt, obwohl alles richtig in allen möglichen Pfaden initialisiert wurde.
Um dort die verbuggte Meldung loszuwegen, ist das Abschalten schon nett. (OK, weil ich garnicht auf die Idee kam, dass man explizit genau Dieses einzeln abschalten kann, wurde dort WARN komplett deaktiviert)

[juergen]

Zitat:

Zitat von Sinspin (Beitrag 1514757)

Ich frage mich ehrlich warum es so einen Unsinn überhaupt gibt!

Prinzipiell hast du Recht, dass diese Compiler-Anweisungen nicht dazu genutzt werden sollen, um unsauberen Code zu „verdecken“.
Es gibt aber durchaus Situationen, wo man das anwenden kann. Z.B. Hinweise auf Plattformabhängigkeiten. Die will ich nicht in den Projektoptionen generell ausschalten, aber bei bestimmten Funktionen möchte ich die Hinweise unterdrücken können.

[dummzeuch]

Zitat:

Zitat von Sinspin (Beitrag 1514757)

Ich frage mich ehrlich warum es so einen Unsinn überhaupt gibt!
Warum soll man dabei unterstützt werden unsauber zu programmieren?

Wo ist im Beispiel eigentlich das Problem die Variable mit einer sinnvollen Farbe zu initialiseren?

Es gibt bei den Warnungen leider auch False Positives, zumindest bei älteren Compilern.
Wenn man es dem alten Compiler dann recht macht, indem man eine Zuweisung einfügt, motzen neuere, dass der zugewiesene Wert nicht benutzt würde. Und schon ist man dann entweder bei IFDEF oder bei WARN xxx OFF.

[himitsu]

auch in noch 11.2

[charly52]

Hi Leute,

die vielen Antworten sind ja schon toll.

ABER, die Frage war:

Weiß jemand ob man mit {$WARN USE_BEFORE_DEF OFF} die Warnung, um die es in der Frage ging, einfach nicht abschalten kann, oder ob ich schlicht was falsch mache.
Der Code steht gar nicht zur Debatte.

Und er ist auch nicht falsch oder gefährlich, sondern einfach so, daß der Compiler an der Stelle, wo die Variable benutzt wird wohl vergessen hat, daß unter der selben Bedingung, die zum zurücksetzen benutzt wird, weiter oben auch ein Wert zugewiesen wurde.

Und entschuldigt bitte die späte Reaktion. War anderweitig unterwegs

Charly

[himitsu]

Nein, der Compilier kann das nicht wissen.
Woher soll er hier wissen, ob diese Funkion oben und unten das gleiche Ergebnis liefert?
Es kann auch sein, dass es nicht so ist und demnach ist diese Meldung vollkommen korrekt.



Hmmmmmm, hier ist am Ende ein ;

Wir hatten schonmal einen ähnlichen Fall.
Da wurde die Überlaufprüfung deaktiviert, aber wenn das wiederanschalten vor dem ; kommt, dann wird es ausgewertet, bevor die die eigentliche Prüfung gemacht wurde und somit war sie weiterhin aktiv.