Wie oft unterläuft euch ein Memleak?
-
knivil schrieb:
RAII "funktioniert" auch ohne Exceptions.
rofl, ne echt? Ich bin dann mal weg, das grenzt ja schon an getrolle.
-
knivil schrieb:
4.) Du legst mir Worte in den Mund.
5.) Mag jeder selbst urteilen, wieviel dein Beitrag mit meiner Person oder mit dem Thema zu tun hat.
6.) Selbstverstaendlich habe ich mich in dieser Zeit nicht veraendert. ...Wenn du ein bißchen weniger arrogant aufträtest, während du fachlich fragwürdige Weisheiten verbreitest, würde es mich auch nicht so in den Fingern jucken. Aber daß du dich verändert hast, sei dir zugestanden; ich sehe ein, daß es nicht besonders nett ist, jemandem vergangene Torheiten vorzuhalten.
knivil schrieb:
Als Beispiel: Liste von allen Kameras abholen, is_GetCameraList: http://www.ids-imaging.de/frontend/files/uEyeManuals/Manual_ger/uEye_Handbuch/index.html . Und sowas muss ich benutzen ... .
Das ist halt eine C-Schnittstelle. Sicher muß man da wissen, wie man mit Fehlercodes eine korrekte Fehlerbehandlung durchführt, wenn man den obligatorischen C++-Wrapper dafür schreibt. Und "die Anzahl der new/delete ausgeglichen zu halten", das ist ja wohl das geringste Problem bei der Fehlerbehandlung; eher verliert man die Übersicht durch die Vielzahl der "Funktionsausgänge", jemand fügt versehentlich ein neues Return-Statement ein und vergißt die damit einhergehenden Obligationen, oder man bedenkt nicht, daß eine der aufgerufenen Funktionen (besonders gemein: Callback-Funktionen) eine Exception werfen kann usw. Kurzum, nach meiner Erfahrung ist Code, der auf Exceptions verzichtet und trotzdem Fehlerbehandlung richtig macht, die absolute Ausnahme. Meistens leakt das Programm nur im erwarteten Fall nicht, und alle oder die meisten anderen Abzweige lassen Ressourcen übrig. Und wie hustbaer feststellt:
hustbaer schrieb:
Und nochmal was das finden angeht: hast du Test-Cases mit 100% Branch-Coverage? Wenn nicht, dann wirst du auch mit den besten Tools nicht 100% aller Leaks finden können.
Ich verstehe jedenfalls nicht, was der Sinngehalt deiner Äußerungen sein soll. Nur echte Männer können Fehlerbehandlung auch ohne RAII? Wer mit Exceptionbehandlung richtig umzugehen weiß, hat sich jedenfalls schonmal Gedanken darüber machen müssen, was im Fehlerfall eigentlich passiert, und ist dadurch schon deutlich begünstigt, wenn du ihn vor dein C mit Klassen setzt. Und sicher gibt es manchmal Fälle, wo man keine Exceptions benutzen kann, weil die Laufzeitumgebung das nicht unterstützt; aber selbst dann nimmt man RAII zu Hilfe und erspart sich manuelle Freigaben, um die obengenannten Probleme einfach systematisch zu umgehen. Kurz, es gibt einfach keinen Grund, neuen Code ohne RAII zu produzieren, wenn dir C++ (mit Destruktoren) zur Verfügung steht.
-
Richtige Memory Leaks haben wir in neurem Code dank RAII keine. Im alten Legacy Code, bzw. Interop Code ab und zu. Mit dem neuren RAII Code haben wir allerdings stellenweise auch Probleme mit dem Speicher, weil Objekte einfach zu lange im Speicher gehalten werden und die Strukturen sehr komplex sind. Also, wenn dann irgendwo Speicherprobleme auftreten, was leider öfter passiert, muss man teilweise schon länger analysieren, wo man Speicher einsparen könnte und Daten früher freigeben, intelligentere MRU Caches schreiben usw. Aber, zum Glück keine richigen Memory Leaks
-
Mechanics schrieb:
weil Objekte einfach zu lange im Speicher gehalten werden
Hm.. interessant. Ich hatte eigentlich noch nie eine Situation, wo das hätte passieren können. Also schon rein vom Konzept her nicht. Insbesondere RAII begünstigt doch eigentlich eine schnelle Freigabe. Könntest du da ein Beispiel nennen?
-
Mechanics schrieb:
Richtige Memory Leaks haben wir in neurem Code dank RAII keine. Im alten Legacy Code, bzw. Interop Code ab und zu. Mit dem neuren RAII Code haben wir allerdings stellenweise auch Probleme mit dem Speicher, weil Objekte einfach zu lange im Speicher gehalten werden und die Strukturen sehr komplex sind.
Das liest sich hier, als wäre RAII eine allumfassende Antwort auf alle Probleme.
Obwohl ich RAII ebenfalls sehr gerne verwende, bleibe ich aber auch den Pointern treu. RAII ist eine sinnvolle Möglichkeit, aber keine Antwort auf alle Probleme, ansonsten hätten Garbage Collections überhaupt keine Diskussionsgrundlage.
Ich bin zwar überhaupt kein Fan von GCs, weil ich liebe fehlerhafte Destruktoren korrigiere als mir gleich ein Monster wie die GC für solche Probleme ins Haus zu holen.
Auch mit RAII darf man den Verstand nicht einfach ausschalten, denn dass sich ''new'' mit RAII komplett ersetzen lässt ist nicht zwangsläufig gegeben.
-
Xin schrieb:
Obwohl ich RAII ebenfalls sehr gerne verwende, bleibe ich aber auch den Pointern treu.
Wieso "obwohl"? Was hat das miteinander zu tun?
Xin schrieb:
Auch mit RAII darf man den Verstand nicht einfach ausschalten, denn dass sich ''new'' mit RAII komplett ersetzen lässt ist nicht zwangsläufig gegeben.
Warum schließen RAII und
newsich aus?Was willst du eigentlich mit deinem Beitrag sagen?
-
Xin schrieb:
RAII ist eine sinnvolle Möglichkeit, aber keine Antwort auf alle Probleme, ansonsten hätten Garbage Collections überhaupt keine Diskussionsgrundlage.
Tja.. ehm.. du hast da schon irgendwo etwas erkannt.
-
Xin schrieb:
Das liest sich hier, als wäre RAII eine allumfassende Antwort auf alle Probleme.
Das wollte ich damit sagen.
-
@Xin
Zum Programmieren braucht man immer ein Gehirn, und darf es auch nie ausschalten.
RAII ist nur - für mich - wirklich eine einzelne Sache die ungleich mehr bringt als vieles was es sonst noch an "good practices" gibt.Natürlich gibt es auch mit RAII Fälle wo die Dinge anfangen etwas kompliziert zu werden.
Diese Fälle sind aber nach meiner Erfahrung ausreichend selten. Wenn ich hin und wieder gut aufpassen muss was ich mache, ist das für mich kein echtes Problem. Wenn ich dagegen bei jeder Zeile aufpassen muss wie ein Haftelmacher ermüde ich viel zu schnell, und fange dann an Fehler zu machen. Und/oder vergleichsweise sehr sehr langsam zu werden.Und was mein "seit RAII quasi keine Leaks mehr" Statement angeht: das ist einfach ne Beobachtung. Meine Konzentrationsfähigkeit ist heute eher schlechter als noch vor 10 Jahren. Wenn ich trotzdem heute deutlich weniger Leaks produziere als damals, kann es also fast nur daran liegen dass ich heute irgendwas grundsätzlich anderes mache. z.B. andere Patterns/Idioms verwenden.
-
kellerassel: leak mir am arsch
-
Die einzige Existenzberechtigung von GCs ist doch, dass sie unter Umständen schneller sein können. Zb wenn es viele kleine Allocations gibt die aufgeräumt werden müssen, zb in Java.
-
hustbaer schrieb:
@Xin
Zum Programmieren braucht man immer ein Gehirn, und darf es auch nie ausschalten.
RAII ist nur - für mich - wirklich eine einzelne Sache die ungleich mehr bringt als vieles was es sonst noch an "good practices" gibt.Das kann man ohne Zweifel so stehen lassen.
hustbaer schrieb:
Natürlich gibt es auch mit RAII Fälle wo die Dinge anfangen etwas kompliziert zu werden. Diese Fälle sind aber nach meiner Erfahrung ausreichend selten.
Bäume? Listen?
hustbaer schrieb:
Wenn ich hin und wieder gut aufpassen muss was ich mache, ist das für mich kein echtes Problem. Wenn ich dagegen bei jeder Zeile aufpassen muss wie ein Haftelmacher ermüde ich viel zu schnell, und fange dann an Fehler zu machen. Und/oder vergleichsweise sehr sehr langsam zu werden.
Dafür fängt man ggfs. aber an, viel zu kopieren, z.B. wenn man Objekte dann in Vectoren packt.
hustbaer schrieb:
Und was mein "seit RAII quasi keine Leaks mehr" Statement angeht: das ist einfach ne Beobachtung. Meine Konzentrationsfähigkeit ist heute eher schlechter als noch vor 10 Jahren. Wenn ich trotzdem heute deutlich weniger Leaks produziere als damals, kann es also fast nur daran liegen dass ich heute irgendwas grundsätzlich anderes mache. z.B. andere Patterns/Idioms verwenden.
Okay, das ist eine subjektive Erfahrung (die ich zwar in ähnlicher Form teile), aber halt keine Garantie.
--------------
Ethon schrieb:
Die einzige Existenzberechtigung von GCs ist doch, dass sie unter Umständen schneller sein können. Zb wenn es viele kleine Allocations gibt die aufgeräumt werden müssen, zb in Java.
Allocations sind in Java nur dann schneller, wenn man in C++ nicht poolt.
Man hat also durchaus Einfluss auf die Umstände. Beim Freigeben ist C++ dann wieder schneller. Der Umstand ist also auch stark davon abhängig, ob das Programm zwischendurch überhaupt den GC benutzt oder einfach nur solange Speicher verteilt, bis am Ende einfach alles jemals genutzte am Stück freigegeben wird.
Das ist natürlich schnell... aber Speicheraufwendig.
-
Ethon schrieb:
Die einzige Existenzberechtigung von GCs ist doch, dass sie unter Umständen schneller sein können. Zb wenn es viele kleine Allocations gibt die aufgeräumt werden müssen, zb in Java.
Das kannst du in C++ ganz leicht global (Allokationsoperatoren überschreiben), oder lokal (eigene Allokatoren nutzen) kontrollieren. Und das genau abgestimmt auf deine Wünsche. Zudem legt man viele kleine Objekte eher auf dem Stack an (was einem GC weit überlegen ist, viele kleine Objekte sind eigentlich oft das Paradebeispiel für das Versagen von GCs), oder reserviert gleich viel Speicher. Jedenfalls hat man alle Möglichkeiten die ein GC hat, außer Speicher umräumen.
-
kellerkindanwärter schrieb:
kellerassel: leak mir am arsch
bist du so gelenig?
-
_D_D schrieb:
kellerkindanwärter schrieb:
kellerassel: leak mir am arsch
bist du so gelenig?
+k
gelenkig wollte ich natürlich schreiben
-
Ausgewaehlte* Statements aus den ersten Antworten:
Selten bis nie, RAII ftw ... bevor ich (vor vielen jahren) angefangen habe RAII zu verwenden hatte ich hin und wieder mal leaks ... haben wir seit konsequenter Anwendung von RAII - i.A. in Form eines Smart-Pointers - genau NULL Probleme ... wei C++ mit RAII keinen Carbage macht ...
Das hat mich irgendwie an schlechte Werbung fuer Putzmittel oder Waschmittel erinnert. Das klingt so, als koenne man nicht Wasche waschen, wenn Persil oder Spee fehlt. Klar ist die vollautomatische Waschmaschine besser als das Scheuerbrett, eine Wahl faellt dabei nicht schwer. Ja gebt mir all die netten Sachen, aber gegen das Meer aus ... schlechter Software kann ich damit wenig ausrichten. Wo kommt all der schlechte Code her?
Dann zur Sache mit dem Neuschreiben: Angenommen mir wird die Zeit gegeben, angenommen ich werde dafuer bezahlt. Angenommen ich habe eine neues funktionierendes Progr ... erstmal nur ein Programm. Angenommen es besteht auch die Tests. Was halte ich dann in den Haenden? Von aussen betrachtet hat es keinen Mehrwert, bis jetzt hat es nur Kosten verursacht, damit der Entwickler ... ruhiger schlafen kann? Vielleicht zahlt es sich in spaeteren Jahren aus, vielleicht auch nicht. Ungewiss!
Und wie macht man das deiner Meinung nach am besten?
Durch Disziplin! Aber mal ehrlich, ich glaube kaum, dass ihr aufgeschmissen seid, wenn ein Aspekt der Sprache wegfaellt. Keine Templates -> eigener Codegenerator, Kein RAII -> na dann wie in C, keine smart_pointer -> dann eben per Hand, kein std::move -> mittels Flag und Kopierkonstrukter . Was haben all die Leute gemacht, als es noch kein C++ gab, die C, Fortran, Pascal ... benutzten? Die waren ja komplett aufgeschmissen.
Ethon schrieb:
Die einzige Existenzberechtigung von GCs ist doch, dass sie unter Umständen schneller sein können. Zb wenn es viele kleine Allocations gibt die aufgeräumt werden müssen, zb in Java.
Ja, die bessere Performance hat den Siegeszug von .Net und Java eingelaeutet. Waehrend C++ noch mit seine RAIIfen beschaeftigt ist, duest Java einfach davon. Nee, mal im Ernst: die Implementation bei manchen lock-free Algorithmen soll einfacher sein. Habe das Geruecht aber nicht weiter verfolgt. Irgend wo bei GoingNative gefallen. Auch sind die Programmierer fuer solche Sprachen billiger. Ok, Lisp, Haskell, ML sind wohl Ausnahmen. Warum die wohl einen GC haben ... . Zumindestens in Scheme gibt es auch RAII speziell fuer Dateien.
*von mir mit einer Absicht
-
Xin schrieb:
Das liest sich hier, als wäre RAII eine allumfassende Antwort auf alle Probleme.
RAII ist die einzige gute Antwort auf Ressourcenmanagement, die ich kenne. Das heißt nicht, dass es nicht andere Wege gibt. Garbage Collection ist jedenfalls kein solcher. Garbage Collection ist imo ein fundamentaler Designfehler, der leider mal eine Zeit lang extrem modern war und mit dem wir heute in manchen Sprachen daher leider leben müssen. So ähnlich wie z.B. der Missbrauch des Singleton Pattern auch...
Xin schrieb:
Obwohl ich RAII ebenfalls sehr gerne verwende, bleibe ich aber auch den Pointern treu.
RAII ist kein Ersatz für Pointer. RAII ist eine Lebenseinstellung...
Xin schrieb:
RAII ist eine sinnvolle Möglichkeit, aber keine Antwort auf alle Probleme, [...]
Natürlich nicht. RAII ist aber die mit großem Abstand beste bekannte Antwort auf so ziemlich alles, was mit Ressourcenmanagement zu tun hat...
Xin schrieb:
[...] ansonsten hätten Garbage Collections überhaupt keine Diskussionsgrundlage.
Ich kenn kein vernünftiges Argument für Garbage Collection, kennst du eins? Garbage Collection ermuntert imo zu schlechtem Design, der GC nimmt einem die Sicht auf viele fundamentale Probleme (die sind natürlich trotzdem noch da, nur merkt mans erst, wenns schon zu spät ist). Ja, solange man erstmal nur schnell irgendwelche Benutzeroberflächen zusammenklicken will, ohne irgendeine Form von anspruchsvoller Logik dahinter, ist man mit GC evtl. anfangs wesentlich schneller, weil viele Dinge, über die man sich eigentlich Gedanken machen müsste, einfach hinter einem komplexen globalen Mechanismus versteckt werden können. Sobald man aber an einen bestimmten Punkt kommt, zeigt sich plötzlich, wie kaputt alles in Wirklichkeit doch ist, das Kartenhaus bricht zusammen und man verbringt ab da die meiste Zeit nun damit, Dinge mit Klebeband zusammenzupappen und Wege zu finden, um den globalen Mechanismus zu überlisten...
Xin schrieb:
Auch mit RAII darf man den Verstand nicht einfach ausschalten, denn dass sich ''new'' mit RAII komplett ersetzen lässt ist nicht zwangsläufig gegeben.
Bist du dir sicher, dass du RAII richtig verstanden hast?
-
cooky451 schrieb:
Jedenfalls hat man alle Möglichkeiten die ein GC hat, außer Speicher umräumen.
Wer sagt denn sowas? ^^
Du musst lediglich statt Pointer Java-Artige-Referenzen verwenden.
-
Garbage Collection ist imo ein fundamentaler Designfehler ... Ich kenn kein vernünftiges Argument ...
Hmm, wenn ich an (funktionale) Sprachen denke im allgemeinen und an echte Continuations im speziellen (nicht setjmp/longjmp)... also ich wuerde das so nicht unterschreiben. Ohne Garbage Collector wohl die Hoelle auf Erden. Ich kenne keine halbwegs funktionale Sprache ohne Garbage Collector. Auch der Vergleich mit dem Userinterface ... hmm ... Nein!
-
Xin schrieb:
hustbaer schrieb:
Natürlich gibt es auch mit RAII Fälle wo die Dinge anfangen etwas kompliziert zu werden. Diese Fälle sind aber nach meiner Erfahrung ausreichend selten.
Bäume? Listen?
Sehe ich jetzt nicht als Problem.
Vielleicht verstehst du unter RAII auch was anderes als ich. Wenn ich RAII schreibe meine ich bloss dass jede Resource bzw. jedes dynamisch erzeugte Objekt zu jedem Zeitpunkt von genau einem anderen Objekt "kontrolliert" wird, und dieses sich im Destruktor um die Freigabe kümmert.
Das muss nicht heissen dass die Besitzverhältnisse nicht wechseln können, oder dass ein Objekt nur genau ein anderes kontrollieren darf.Bei Listen besitzt z.B. einfach die Liste alle Nodes. Wenn man Nodes "ausklinken" will kann man sie entweder ala std::list in eine neue Liste raustrennen, oder einfach nen std::unique_ptr (bzw. vor C++11 einen std::auto_ptr) zurückgeben.
Bei Bäumen kann entweder der Baum alle Nodes besitzen, oder der Baum besitzt die Root-Node, und alle Nodes besitzen ihre unmittelbaren Kinder.
Klar muss man dabei aufpassen während man die Liste oder den Baum selbst implementiert, aber bei der Verwendung muss man sich dann keine Sorgen mehr machen dass irgendwas nicht oder doppelt freigegeben werden könnte.
Und das ist für mich in Summe dann "ausreichend selten". Zumindest ich implementiere wesentlich weniger oft Datenstrukturen als ich sie dann verwende. (Und meist komme ich sowieso mit den vorgegebenen Datenstrukturen der STL bzw. Boost aus.)
hustbaer schrieb:
Wenn ich hin und wieder gut aufpassen muss was ich mache, ist das für mich kein echtes Problem. Wenn ich dagegen bei jeder Zeile aufpassen muss wie ein Haftelmacher ermüde ich viel zu schnell, und fange dann an Fehler zu machen. Und/oder vergleichsweise sehr sehr langsam zu werden.
Dafür fängt man ggfs. aber an, viel zu kopieren, z.B. wenn man Objekte dann in Vectoren packt.
Was manchmal auch vollkommen OK ist, weil 80/20 und so.
Bei den "20% des Codes" Stellen muss man dann halt wieder sein Hirn einschalten wenn das viele Kopieren zu einem Problem wird. Aber auch nicht bei jeder Zeile Code, siehe oben.hustbaer schrieb:
Und was mein "seit RAII quasi keine Leaks mehr" Statement angeht: das ist einfach ne Beobachtung. Meine Konzentrationsfähigkeit ist heute eher schlechter als noch vor 10 Jahren. Wenn ich trotzdem heute deutlich weniger Leaks produziere als damals, kann es also fast nur daran liegen dass ich heute irgendwas grundsätzlich anderes mache. z.B. andere Patterns/Idioms verwenden.
Okay, das ist eine subjektive Erfahrung (die ich zwar in ähnlicher Form teile), aber halt keine Garantie.
Ja, klar. Im Endeffekt sind das doch alles nur subjektive Erfahrungen bzw. Meinungen.
