Warnung W1036 Variable nicht initialisiert bei Verwendung FreeAndNil()

[Neutral General]

Ja da stimm ich dir zu, falls du über den Code redest den ich in meinem Post nochmal gepostet habe 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 von Neutral General:

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.