Alle Memory Leaks beseitigen

[Popov]

Wie schon erwähnt, inherited ist an der Stelle nicht wirklich wichtig, aber ich erkenne daran immer ganz schnelle die Konstruktoren und Destruktoren.

Delphi-Quellcode:

constructor TJsonObject.Create;
begin
  inherited;
  FKeys := TStringArray.Create;
  FValues := TJsonValues.Create;
end;

destructor TJsonObject.Destroy;
begin
  FValues.Free;
  FKeys.Free;
  inherited;
end;

Ich muss zugeben, dass ich gerade erst aufgestanden bin und erst meinen Kaffee trinke. Was wird hier noch mal gemacht?

Delphi-Quellcode:

procedure TJsonObject.Parse(AJsonText: string);
...
begin
...
          AddValue(CurrentKey, TJsonValue.Create);                             //<<<<<<<<<<<<<<<<<<<<<<<

Ich will nicht behaupten, dass das etwas ist, ich kenne nur diese Technik nicht. Die geibt es hier noch mal:

Delphi-Quellcode:

procedure TJsonValue.GetValue(var AOutput: TJsonArray);
...
begin
...
      LJsonArray.Add(TJsonValue.Create);                                        //<<<<<<<<<<<<<<<<<<

Dann hier noch was:

Delphi-Quellcode:

procedure TJsonValue.GetValue(var AOutput: TJsonArray);
...
begin
...
  LJsonArray := TJsonArray.Create;                                              //<<<<<<<<<<<<<<<<<<<<<<<<<

Ich hab mir angewöhnt immer mit try finally zu arbeiten. Erstelle ich ein Objekt, ist die nächste Zeile ein try . Der Rest ergibt sich dann automatisch. Vergesse ich finally , gibt es Krach. Schreibe ich es, gebe ich auch alles wieder frei.

Hier gibst du etwas ein. Gibst du es wieder frei?

Delphi-Quellcode:

procedure TJsonArray.Add(AJsonValue: TJsonValue);
begin
  SetLength(FValues, Count+1);
  FValues[Count-1] := AJsonValue;
end;

procedure TJsonArray.Clear;
begin

end;

Wie gesagt, das auf die Schnelle ohne den Code genauer zu studieren.

[himitsu]

Zitat:

Delphi-Quellcode:

procedure TJsonArray.Clear;
begin

end;

destructor TJsonObject.Destroy;
begin
  FValues.Free;

Und wann werden die Items in dieser Liste freigegen?
-> nie

Entweder du machst das selber oder du nimmst eine TObjectList / TObjectList<T> mit OwnsObjects=True.

Ich würde auch eines der vielen Tutorials bezüglich Fehlerbehandlung empfehlen.
Wenn ich z.B. ein "neues" Objekt zurückgebe und zwischen der Erstellung und dem Methodenende Fehler auftreten könnten, dann wird das immer via Try-Except abgesichert.

Delphi-Quellcode:

function Test: TObject;
begin
  Result := TObject.Create;
  ...  // hier irgendwas "Gefährliches" machen
end;  // bei einer Exception kümmert sich keiner mehr um die Freigabe des Objektes

function Test: TObject;
begin
  Result := TObject.Create;
  try
    ...  // hier irgendwas "Gefährliches" machen
  except
    Result.Free;  // bei Fehler wieder Freigeben
    raise;  // und abgefangenen Fehler weiterreichen
  end;
end;

[Popov]

Jep. TObjectList ist eine feine Sache. Im Gegensatz zu anderen Klassen die Objekte aufnehmen (zumindest in D7, später, habe ich mir sagen lassen, können das auch andere Klassen), kann man TObjectList mit Objekten bis oben hin vollknallen. Beim richtigen Parameter wird dann alles automatisch wieder freigegeben.

[himitsu]

Ja, aber leider hat z.B. schainbar irgendein Idiot nicht richtig mitgedacht.
CrossPlattform-Entwicklung ist einfach nur bähhhh.

In den Schnittstellen der LiveBindings wird TList<T> verwendet.
Im NextGen ist TList<T> und TObjectList<T> quasi das Selbe, da dort praktisch alle Objekte über das ARC automatisch freigegeben werden, sobald es nirgendwo mehr eine Referenz gibt,
aber in den notmalen Compilern fehlt dort plötlich das OwnsObjects.