nicht initialisierte Variable erzeugt keine Warnung/Hinweis

[Incocnito]

Das FreeAndNil sehe ich gar nicht mal als Problem.
Ich könnte ja auch Funktionen nutzen um Variablen zu initialisieren:

Delphi-Quellcode:

Procedure Testa(var test : TStringList);
Begin
  test := TStringList.Create();
  test.Add('Testzeile');
End;

Procedure Testb();
var
  slTemp : TStringList;
Begin
  Testa(slTemp); // alles wunderbar
  ShowMessage(slTemp.Text);
  slTemp.Free();
End;

Das Problem ist eher, dass er bei "sl.Text = '';" direkt in der ersten Zeile,
nicht meckert, obwohl "sl" definitiv nicht initialisiert ist.
Wird das wohl durch "try-except" wegoptimiert?

Und lokale Variablen muss man trotzdem freigeben.
Arrays braucht man nicht mit "SetLength(x, 0);" freigeben,
aber sonst muss alles, was erzeugt wird auch freigegeben werden.
Ahja: Interfaces haben einen Referenzzähler, so dass das noch
wieder anders läuft.
Auch zur Laufzeit erstellte Komponenten muss man nicht unbedingt freigeben,
weil sie ja einem Parent zugeordnet werden und freigegeben werden, wenn
das Parent freigegeben wird.
Mehr Außnahmen fallen mir gerade nicht ein, ansonsten empfehle ich MadExcept
zum Testen auf Speicherlecks.

MfG Incocnito

[jaenicke]

Es wird immer Konstellationen geben, in denen der Compiler nicht warnt oder nicht warnen kann. Von daher finde ich es gut, dass in vielen Fällen gewarnt wird, verlasse mich aber nicht darauf.

Es gibt auch diverse Tools, die zusätzliche Analysen machen:
TMS FixInsight, Pascal Analyzer, CodeHealer, ...

Zitat:

Zitat von Incocnito (Beitrag 1451281)

Auch zur Laufzeit erstellte Komponenten muss man nicht unbedingt freigeben,
weil sie ja einem Parent zugeordnet werden und freigegeben werden, wenn
das Parent freigegeben wird.

Owner <> Parent!
Der Owner kümmert sich um die Freigabe, das Setzen des Parents bestimmt wo die Komponente angezeigt wird.

[DeddyH]

Auch der Parent geht im Destruktor sein Controls-Array durch und gibt die darin enthaltenen Elemente frei.

[Incocnito]

Zitat:

Zitat von Frühlingsrolle (Beitrag 1451284)

Hier wir das Objekt slTemp in der Funktion Testa() initilialisiert, und diese wird in Testb() aufgerufen. Wo ist das Problem?

Exakt darauf wollte ich hinaus! ;)

Zitat:

Zitat von DeddyH (Beitrag 1451300)

Auch der Parent geht im Destruktor sein Controls-Array durch und gibt die darin enthaltenen Elemente frei.

Exakt daran dachte ich auch ... das "Parent <> Owner" gibt mir gerade zu denken.

Abgesehen davon gehe ich bei selbst erstellten Komponenten immer hin und gebe die auch von Hand frei,
ich weiß halt nur, dass es wohl scheinbar auch ohne diesen Aufwand ohne Speicherlecks gehen soll.

MfG Incocnito

[Stevie]

https://quality.embarcadero.com/browse/RSP-19835

[jaenicke]

Zitat:

Zitat von Incocnito (Beitrag 1451304)

Zitat:

Zitat von DeddyH (Beitrag 1451300)

Auch der Parent geht im Destruktor sein Controls-Array durch und gibt die darin enthaltenen Elemente frei.

Exakt daran dachte ich auch ... das "Parent <> Owner" gibt mir gerade zu denken.

Dann habe ich mich da geirrt.

[AJ_Oldendorf]

Fehler existiert in D10.4 immernoch.
Neuen Bug-Report aufgemacht. Bitte voten...

https://quality.embarcadero.com/browse/RSP-29516

[Der schöne Günther]

Ist natürlich ärgerlich, aber weshalb war es nötig dafür noch ein Ticket aufzumachen?

[AJ_Oldendorf]

Ich dachte mir, wenn der andere Report nicht bearbeitet wird, wird er vielleicht bearbeitet wenn er unter dem neusten Delphi steht. Da gucken die Entwickler vielleicht eher drauf und reagieren, weil dazu noch einige Updates kommen werden.

[AJ_Oldendorf]

Mein Report wurde gerade geschlossen mit Verweis auf den Report von Bernhard Geyer
Leider existiert dieser ja schon seit einigen Versionen.
@Bernhard Geyer: Kannst du dein Report mal aktualisieren, dass dieser Fehler auch noch in 10.4 enthalten ist? Es steht ja nur dabei, dass dieser in 10.2 vorhanden ist. Vielleicht wird er dann eher bearbeitet weil gevotet wurde ja schon dafür