Delphi Bugs mit Lösungen...

[Mavarik]

Hallo Zusammen...

Ich dache mir, ich mache mal einen Thread auf mit Bugreports die Ich gepostet habe und bei denen die Lösung schon enthalten ist...

Ich habe kein Projekt bei dem ich nicht wenigstens 2-3 Source-Files aus dem Delphi Source-Dir in mein Projekt mit meinen Fixes rüber ziehe.

Hier mein letzter:

Memory Leak in TFontGlyphManager mein QC (RSP-17256) ist closed, daher habe ich die Infos in RSP-18012 geschrieben.

Änderungen in FMX.FontGlyphs.pas

Delphi-Quellcode:

destructor TFontGlyphManager.Destroy;
begin
  FreeResource;

  if Assigned(FMethods) then // 
    FMethods.Free;           // Fehlte
 
  inherited;
end;

und in
class function TFontGlyphManager.InternalGetFontGlyphManager: TFontGlyphManager;

Delphi-Quellcode:

// end;// 2 Zeilen tiefer
   FCurrentManager.FMethods := TList<TMethodDescriptor>.Create; // Nur 1x
end;

Mavarik

[mensch72]

wenn ich Zeit habe und die "rechtliche Freigabe" bekomme, veröffentliche ich auch mal ein paar unserer (alten) BLE Fixes... Delphi/FMX für IoT wird groß beworben, aber da "komische" Sachen seit XE8.1 teils immer weiter führen... wird langsam anstrengend

Aber Asche auf unser Haupt:
1. klar nutzt das kaum jemand und hier ist CrossPlattform + CrossHardwareStandard(BLE4.0->4.1->4.2) ne echte Herausforderung
2. wer es "wirklich" nutzt und weiß wie es (trotzdem)geht verrät es oft nicht gern öffentlich und erstellt daher keine QC Einträge

[Uwe Raabe]

Zitat von Mavarik:

Delphi-Quellcode:

  if Assigned(FMethods) then // 
    FMethods.Free;           // Fehlte

Das if Assigned kannst du dir sparen, das macht das Free selbst. Unter ARC wird das vom Compiler sowieso durch eine nil-Zuweisung ersetzt, was die Abfrage ebenso obsolet macht.

[Mavarik]

Zitat von Uwe Raabe:

Zitat von Mavarik:

Delphi-Quellcode:

  if Assigned(FMethods) then // 
    FMethods.Free;           // Fehlte

Das if Assigned kannst du dir sparen, das macht das Free selbst. Unter ARC wird das vom Compiler sowieso durch eine nil-Zuweisung ersetzt, was die Abfrage ebenso obsolet macht.

Auf eine Methode eine Klasse zuzugreifen ohne zu testen, ob die Klasse Assigned ist - widerstrebt mir einfach...

[Darlo]

Zitat von Mavarik:

Delphi-Quellcode:

  if Assigned(FMethods) then // 
    FMethods.Free;           // Fehlte

Sollte das nicht besser so heißen?

Delphi-Quellcode:

  if Assigned(FMethods) then 
  {$IFDEF AUTOREFCOUNT}
    FMethods.DisposeOf;
  {$ELSE}
    FMethods.Free;

Warum wird im Free eigentlich nicht geprüft ob ARC und dann DisposeOf aufgerufen? Würde ne Menge an Code sparen.

[Uwe Raabe]

Zitat von Darlo:

Warum wird im Free eigentlich nicht geprüft ob ARC und dann DisposeOf aufgerufen? Würde ne Menge an Code sparen.

Weil Free unter ARC eben gar nicht aufgerufen wird! Der Compiler ersetzt das einfach durch eine nil-Zuweisung.

[Darlo]

Dann könnte der Compiler das doch durch disposeof ersetzen

[Fritzew]

Zitat von Darlo:

Dann könnte der Compiler das doch durch disposeof ersetzen

Und für was sollte das dann gut sein?
Disposeof wird nur benötigt wenn da mehrere Referenzen auf das selbe Object sind, und Ressourcen freigegeben werden müssen.
Ansonsten besteht keinerlei Grund das einzusetzen.

[Uwe Raabe]

Zitat von Darlo:

Dann könnte der Compiler das doch durch disposeof ersetzen

Nicht unbedingt, denn DisposeOf macht etwas anders als eine nil-Zuweisung.

[Stevie]

Waddn gruseliger Code ist das denn in TFontGlyphManager

Das können nur Artefakte aus VGScene Zeiten sein, wo noch Delphi 7 und andere Versionen unterstützt wurden, die noch kein class constructor/destructor kannten...

RegisterCharacterHandleMethod und UnRegisterCharacterHandleMethod sind übrigens auch defekt, die krachen nämlich, wenn vorher nicht TFontGlyphManager.Current aufgerufen wurde. Das muss man aber nicht machen, weil das ja eh statische Methoden sind (soll heißen, ich kann TFontGlyphManager.RegisterCharacterHandleMethod aufrufen). Das wiederum lässt mich vermuten, dass man FMethods früher (class constructor?) erzeugen und im entsprechenden destructor wieder freigeben sollte.