Warnung W1036 Variable nicht initialisiert bei Verwendung FreeAndNil()

[Ralle1]

Moin zusammen,

ist vermutlich ein alter Hut, bin aber trotzdem gerade drüber gestolpert und wollte mal wissen, was es damit auf sich hat:

Folgende Methode erzeugt berechtigter Weise die Warnung "[DCC Warnung] UnitTest.pas(36): W1036 Variable 'StringList' ist möglicherweise nicht initialisiert worden":

Delphi-Quellcode:

procedure TFormTest.Button1Click(Sender: TObject);
var
  StringList : TStringList;
  i : integer;
begin
  i := 1;
  if i=0 then
    StringList := TStringList.Create;
  StringList.Add('Rumms');
  StringList.Free;
end;

Nun irritiert es mich, dass die Warnung nicht mehr kommt, wenn man FreeAndNil einsetzt:

Delphi-Quellcode:

procedure TFormTest.Button2Click(Sender: TObject);
var
  StringList : TStringList;
  i : integer;
begin
  i := 1;
  if i=0 then
    StringList := TStringList.Create;
  StringList.Add('Rumms');
  FreeAndNil(StringList);
end;

Im Einsatz ist Delphi XE2. Würde ich als Bug einstufen, weiß jemand mehr dazu ?

[DeddyH]

Ich vermute, dass das damit zu tun hat, dass Free eine Methode (von TObject) ist, FreeAndNil hingegen eine reguläre Prozedur, die der Compiler nicht dahingehend prüfen kann.

[baumina]

Interessanterweise kann das FreeAndNil auch an anderer Stelle stehen, ohne dass eine Warnung kommt (Delphi XE).

Delphi-Quellcode:

procedure TFormTest.Button2Click(Sender: TObject);
var
   StringList : TStringList;
   i : integer;
begin
   FreeAndNil(StringList);
   i := 1;
   if i=0 then
     StringList := TStringList.Create;
   StringList.Add('Rumms');
end;

[Ralle1]

@DeddyH
das alleine kann es nicht sein:
Lasse ich im 1. Fall das Free weg, kommt die Warnung trotzdem, weil ich ja schließlich mit StringList.Add auf das Objekt zugreife.
Also FreeAndNil verbirgt auch die Warnung, die man für StringList.Add erwartet hätte.

[DeddyH]

Stimmt, das hab ich übersehen.

[Neutral General]

Ist kein Wunder.
Das Objekt (in dem Fall die Stringlist) wird als var-Parameter an FreeAndNil übergeben.
Und Delphi kann nicht wissen was in FreeAndNil gemacht wird. Es könnte sehr gut sein, dass FreeAndNil das übergebene Objekt erstellt/initialisiert.

[himitsu]

Nunja, eigentlich kann Delphi das wissen.

Bei VAR muß die Variable initialisiert sein, denn Delphi kann ja nicht wissen, ob mit der Variable intern was gemacht wird.

Darum gibt es auch die OUT-Parameter, wo nichts rein geht, aber etwas raus kommt.
Und genau das OUT müsste der Entwickler verwenden, wenn er das von dir genannte Szenario implementieren will.

[DeddyH]

Das alles erklärt aber immer noch nicht #4.

[Neutral General]

Wieso erklärt das #4 nicht?

Das einzige was in meinen Augen falsch ist, ist dass bei:

Delphi-Quellcode:

procedure TFormTest.Button2Click(Sender: TObject);
var
  StringList : TStringList;
  i : integer;
begin
  i := 1;
  if i=0 then
    StringList := TStringList.Create;
  StringList.Add('Rumms');
  FreeAndNil(StringList);
end;

keine Warnung kommt. Wenn das FreeAndNil vor dem Add stehen würde und keine Warnung käme dann kann ich das wie oben schon gesagt nachvollziehen. Aber so müsste Delphi erkennen dass es beim .Add möglicherweise knallen kann.

@himitsu: Bei var MUSS gar nichts :P Technisch können var und out gleichbedeutend benutzt werden meiner Erfahrung nach. Und weil es MÖGLICH ist als var-Parameter ein nil/uninitialisiertes Objekt zu übergeben und ein inititalisiertes zurückzubekommen ist die nicht vorhandene Warnung gerechtfertigt.

[DeddyH]

Aber dass die Warnung beim Add unterbleibt ist doch eben das Merkwürdige.

[Neutral General]

Ja da stimm ich dir zu, falls du über den Code redest den ich in meinem Post nochmal gepostet habe :mrgreen: In allen anderen bisher gezeigten Fällen kann ich den Compiler verstehen und denke dass er Recht hat.

[himitsu]

Ja, bei VAR muß nichts reingegeben werden, aber wenn man will, daß der Compiler entsprechende Meldungen ausgibt, dann muß man es dennoch entsprechend angeben

OUT = nicht rein, aber etwas raus
VAR = etwas rein, welches verändert wieder rauskommen könnte
CONST und IN NICHTS = etwas rein und das ändert sich auch nicht

Denn nur dann kann der Compiler auch eine ordentliche Prüfung vornehmen.

[jfheins]

Mein Senf dazu: Delphi ist da (inzwischen) etwas unterentwickelt was Warnungen angeht. (Want also an Stellen nicht, wo eine Warnung angebracht wäre)

Zitat:

Zitat von Neutral General (Beitrag 1280639)

Und weil es MÖGLICH ist als var-Parameter ein nil/uninitialisiertes Objekt zu übergeben und ein inititalisiertes zurückzubekommen ist die nicht vorhandene Warnung gerechtfertigt.

Ich lese da heraus, dass du für das Fehlen der Warnung Verständnis hast. Geht mr nicht so. Im Gegenteil, genau das wäre für mich eine Warnung. Gerade weil der Compiler nicht mit Sicherheit sagen kann, dass es falsch ist. (Keine Warnung bei Verwendung von out statt var)
Kann der Compiler nachweisen, dass die nicht-initialisierte Variable benutzt wird, als wäre sie initialisiert (was er können sollte aber in Delphi nicht kann), dann sollte es einen Fehler geben.
Denn so ein Programm wird nicht richtig funktionieren und dann mit einer AV abstürzen.

Ich weiß, diese Vergleiche sind unbeliebt, aber dennoch:

Code:

      public static void Test()
      {
         int i = 1;
         List<string> StringList;
         if (i == 0)
         {
            StringList  = new List<string>();
         }
         StringList.Add("Rumms"); //Fehler CS0165:   Verwendung der nicht zugewiesenen lokalen Variablen 'StringList'    in Zeile 30

         StringList = null;
      }

[Dejan Vu]

Der Compiler kann bei der Methode FreeAndNil das Constraint erkennen, das die Variable über alle Codepfade am Ende den Wert null hat. Zumindest könnte er das erkennen. Codepfade sind nichts anderes als Graphen und so eine Graphtraversierung ist weder NP-Komplett noch sonst irgendwie komplex. Nur macht das der Delphi Compiler nicht. Es werden irgendwelche Heuristiken verwendet, die eben dann zu falschen Ergebnissen führen, wie im Beispiel von Baumina.

Aber der eigentlich Fehler ist ja nicht der, das *am Ende* der Routine 'FreeAndNil' aufgerufen wird, sondern der einfache Aufruf *am Ende* dazu führt, das der Aufruf der Methode 'Add' nicht mehr als verdächtig eingestuft wird. Ob da VAR oder OUT steht oder beides, ist doch vollkommen wurscht.

Können die noch nicht einmal einen anständigen Compiler bauen?

[himitsu]

Win32 ist noch der alte Compiler und der soll ja auch bald ersetzt werden.