Delphi-PRAXiS
Seite 2 von 2     12   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Object-Pascal / Delphi-Language (https://www.delphipraxis.net/32-object-pascal-delphi-language/)
-   -   Delphi Warum meckert FastMM hier ein Speicherleck an? (https://www.delphipraxis.net/199020-warum-meckert-fastmm-hier-ein-speicherleck.html)

Benmik 19. Dez 2018 16:41

AW: Warum meckert FastMM hier ein Speicherleck an?
 
Das Problem wurde durch hoika gelöst.

Die Stelle, die mir - im Nachhinein gesehen - hätte auffallen müssen, lautet:
Delphi-Quellcode:
JamPathList := JamShellLink.SelectionList.GetListOfAllFiles;
Dort wird eine TStringList zurückgegeben, die in GetListOfAllFiles erzeugt wird. JamPathList muss/darf also gar nicht erzeugt werden, daher ganz richtig das Speicherleck. Tschuldigung, FastMM!

Meiner Meinung nach ist die Routine ein Verstoß gegen das Gebot, dass Objekte dort freigegeben werden sollen, wo sie auch erzeugt werden. Daher hatte ich nicht damit gerechnet, hätte es aber müssen, denn was soll
Delphi-Quellcode:
JamPathList := ...
anderes bedeuten? Danke nochmal.

hoika 19. Dez 2018 16:53

AW: Warum meckert FastMM hier ein Speicherleck an?
 
Hallo,
sehe ich auch so.
Eigentlich müsste der Methode eine selbst erzeugte Liste übergeben werden.

Wir haben hier ein paar ehemalige Java-Programmierer.
Die wollen das auch so machen, der Garbage Collector gibt ja schon alles frei.

Das aus den Köpfen zu bekommen, da sitze ich immer noch dran ...

Benmik 19. Dez 2018 17:20

AW: Warum meckert FastMM hier ein Speicherleck an?
 
Zitat:

Zitat von hoika (Beitrag 1421293)
Eigentlich müsste der Methode eine selbst erzeugte Liste übergeben werden.

Genau!

Interessant auch, wie zielgenau ich exakt diejenige Codezeile, die zur Lösung geführt hätte, als scheinbar (ja, scheinbar, nicht anscheinend!) unwichtig weggelassen hatte.

Auf der anderen Seite wundere ich mich immer, wie hier die Experten einen Fullpost von 500 Zeilen offenbar mit Lichtgeschwindigkeit durchparsen. Wahrscheinlich dauert es nicht mehr lang, bis die Compilerisierung eines Programmiererhirns als Berufskrankheit anerkannt wird.

freimatz 20. Dez 2018 13:04

AW: Warum meckert FastMM hier ein Speicherleck an?
 
Zitat:

Zitat von hoika (Beitrag 1421293)
Hallo,
Wir haben hier ein paar ehemalige Java-Programmierer.
Die wollen das auch so machen, der Garbage Collector gibt ja schon alles frei.
Das aus den Köpfen zu bekommen, da sitze ich immer noch dran ...

Es wäre m.E. besser EMB würde mal dran sitzen um das Problem zu lösen. Ich verwende wo immer es geht interfaced Objekte. Zwar gilt auch "Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher" - jedoch habe ich hier auf Erden noch nie einen gefunden, der das fehlerfrei beherrscht. :P

Benmik 20. Dez 2018 14:50

AW: Warum meckert FastMM hier ein Speicherleck an?
 
Da würde mich interessieren, auf welchem programmatischen Wege Emba das Problem lösen könnte.

freimatz 20. Dez 2018 17:27

AW: Warum meckert FastMM hier ein Speicherleck an?
 
So wie es C# macht oder Delphi bei den interfaced Klassen. Da geht es ja auch.
Für eine einfache Klasse nur deswegen ein interface zu machen ist oft recht lästig.

Benmik 20. Dez 2018 17:31

AW: Warum meckert FastMM hier ein Speicherleck an?
 
Oh, du meinst Garbage Collection einführen? Was macht dann himitsu? Seine Signatur ist doch mittlerweile eingebrannt und nicht mehr änderbar.

Meine Privatmeinung als Amateur: Wäre eine fundamentale Sprachänderung und erscheint undurchführbar.

freimatz 21. Dez 2018 10:20

AW: Warum meckert FastMM hier ein Speicherleck an?
 
Nein, ich meine nicht Garbage Collection sondern Referenzzählung.
Allerdings lag ich mit C# falsch, die haben keine Referenzzählung sondern doch Garbage Collection.

Die Signatur ist eingebrannt? Aber dann ist sie doch Müll. Daraus folgt dass himitsu kein Delphianer ist :-P


Alle Zeitangaben in WEZ +1. Es ist jetzt 21:34 Uhr.
Seite 2 von 2     12   

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz