AGB  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Delphi Bugs mit Lösungen...

Ein Thema von Mavarik · begonnen am 19. Mai 2017 · letzter Beitrag vom 20. Mai 2017
Antwort Antwort
Seite 1 von 2  1 2   
Foren-Tage 2017
DIE Konferenz für Delphi-Entwickler mit vielen Vorträgen und ganztägigen Workshops, veranstaltet u.A. von der Delphi-PRAXiS und Embarcadero.
21.-23. September 2017 in Hamburg · Mehr Infos unter forentage.de.
Benutzerbild von Mavarik
Mavarik

Registriert seit: 9. Feb 2006
Ort: Stolberg (Rhld)
3.632 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#1

Delphi Bugs mit Lösungen...

  Alt 19. Mai 2017, 14:05
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
  Mit Zitat antworten Zitat
mensch72

Registriert seit: 6. Feb 2008
456 Beiträge
 
#2

AW: Delphi Bugs mit Lösungen...

  Alt 19. Mai 2017, 14:38
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
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe
Online

Registriert seit: 20. Jan 2006
Ort: Lübbecke
4.908 Beiträge
 
Delphi 10.2 Tokyo Architect
 
#3

AW: Delphi Bugs mit Lösungen...

  Alt 19. Mai 2017, 14:39
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.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Benutzerbild von Mavarik
Mavarik

Registriert seit: 9. Feb 2006
Ort: Stolberg (Rhld)
3.632 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#4

AW: Delphi Bugs mit Lösungen...

  Alt 19. Mai 2017, 14:56
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...
  Mit Zitat antworten Zitat
Darlo

Registriert seit: 28. Jul 2008
Ort: München
1.113 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#5

AW: Delphi Bugs mit Lösungen...

  Alt 19. Mai 2017, 15:01
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.
Philip
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe
Online

Registriert seit: 20. Jan 2006
Ort: Lübbecke
4.908 Beiträge
 
Delphi 10.2 Tokyo Architect
 
#6

AW: Delphi Bugs mit Lösungen...

  Alt 19. Mai 2017, 15:04
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.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Darlo

Registriert seit: 28. Jul 2008
Ort: München
1.113 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#7

AW: Delphi Bugs mit Lösungen...

  Alt 19. Mai 2017, 15:06
Dann könnte der Compiler das doch durch disposeof ersetzen
Philip
  Mit Zitat antworten Zitat
Fritzew

Registriert seit: 18. Nov 2015
Ort: Kehl
333 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#8

AW: Delphi Bugs mit Lösungen...

  Alt 19. Mai 2017, 15:11
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.
Fritz Westermann
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe
Online

Registriert seit: 20. Jan 2006
Ort: Lübbecke
4.908 Beiträge
 
Delphi 10.2 Tokyo Architect
 
#9

AW: Delphi Bugs mit Lösungen...

  Alt 19. Mai 2017, 15:14
Dann könnte der Compiler das doch durch disposeof ersetzen
Nicht unbedingt, denn DisposeOf macht etwas anders als eine nil-Zuweisung.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
3.263 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#10

AW: Delphi Bugs mit Lösungen...

  Alt 19. Mai 2017, 16:39
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.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight

Geändert von Stevie (19. Mai 2017 um 16:49 Uhr)
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2   

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 18:12 Uhr.
Powered by vBulletin® Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2017 by Daniel R. Wolf