...wenn free oder delete vergessen wird
-
Unsinn, bei Qt räumt ein parent seine Kinder auf.
-
...wenn free oder delete vergessen wird
Dann kommt man in die Hölle...
-
Tyrdal schrieb:
Unsinn, bei Qt räumt ein parent seine Kinder auf.
Hmm, macht auch mehr Sinn. Muss ich wohl falsch in Erinnerung gehabt haben, habe Qt schließlich seit sehr vielen Monden nicht mehr angefasst
-
SeppJ schrieb:
Abgesehen von historischen Betriebssystemen deutet ein "vergessenes" free aber auf einen Logikfehler im Programm hin. Wobei dieser Fehler auch sein kann, dass der Programmierer einfach nicht weiß, wie man es richtig macht.
Biste wieder weit ausm Fenster.
Stichwort (de)initialization order fiasco.
Lieber einfach weglassen. Funktioniert.
-
Lieber einfach weglassen. Funktioniert.
Ist das nicht auf die Dauer tödlich? Also bei vielen Objekten? Oder reden wir hier von ein paar Kilobytes?
-
Also ich zumindest rede von Singletons bzw. allgemein statischen/globalen Objekten, denn genau bei denen gibt es das (de)initialization order fisaco. OK, vollständig heisst es static (de)initialization order fisaco. Das "static" wäre wohl ein guter Tip gewesen, hätte ich vielleicht nicht weglassen sollen
-
hustbaer schrieb:
Also ich zumindest rede von Singletons bzw. allgemein statischen/globalen Objekten, denn genau bei denen gibt es das (de)initialization order fisaco. OK, vollständig heisst es static (de)initialization order fisaco. Das "static" wäre wohl ein guter Tip gewesen, hätte ich vielleicht nicht weglassen sollen
Nichts desto trotz hat SeppJ 100% recht.
-
Sagst du.
Ich sag' das Gegenteil.
Und nu?
-
hustbaer schrieb:
Sagst du.
Ich sag' das Gegenteil.
Und nu?Du könntest ja Argumente bringen, aber das wäre langweilig weil man ein "Fehlendes delete deutet auf Logikfehler hin" nicht widerlegen kann. Es deutet nunmal auf einen Logikfehler hin - es ist nicht jedesmal zwingend einer, aber es deutet darauf hin.
Auch wenn du dir Situationen konstruieren kannst wo ein fehlendes delete kein Logikfehler ist, widerlegst du SeppJs Aussage damit nicht.
-
Ich hasse es, dass man in diesem Forum jede Antwort auf selbst einfachste Fragen mit 10 Seiten Disclaimern für alle vorstellbaren und unvorstellbaren Sonderfälle versehen muss. Da antworte ich teilweise lieber gar nicht mehr. Wurde mal wieder bestätigt.
-
SeppJ schrieb:
Ich hasse es, dass man in diesem Forum jede Antwort auf selbst einfachste Fragen mit 10 Seiten Disclaimern für alle vorstellbaren und unvorstellbaren Sonderfälle versehen muss. Da antworte ich teilweise lieber gar nicht mehr. Wurde mal wieder bestätigt.
das ist wohl eine Informatikerkrankheit.
Irgendwer kommt immer mit einem Spezialfall daher, der gegen die Argumentation spricht. Meist in der Form "...aber TotalTollesFrameworkXY macht das anders ..."Ich darf jeden Tag in der Arbeit dieses Spiel spielen, sei froh dass es dich nur im Forum trifft
-
Das ist diesmal keine Disclaimerkrankheit, sondern eine Unfugkrankheit.
Stimmt nicht schrieb:
Arcoth schrieb:
Das OS räumt nach Prozessende auf.
Das hängt vom OS ab.
DOS, AmigaOS, AROS und Win9x/Me können das meistens nicht.Unfug. Beim Speicher klappts mit DOS und Win95 auch sauber. AmigaOS und AROS kenne ich nicht, glaube Dir aber ganz einfach nicht, daß die den Speicher nicht freigeben. Soweit sind malloc/free kein Problem.
Um Speicher ging es in der Frage. new/delete kann auch beliebige andere Ressourcen binden. Win95 kann auch alle anderen Betriebssystemressourcen bis auf wenige Ausnahmen wie file locks. DOS hat keine anderen Betriebssystemressourcen, oder? Oh, TSR-Speicher wird nicht freigegeben, das ist aber kein Bug, sondern ein Feature.
-
hustbaer schrieb:
Sagst du.
Ich sag' das Gegenteil.
Und nu?Nimm weniger Drogen beim Posten.
-
Tyrdal schrieb:
Unsinn, bei Qt räumt ein parent seine Kinder auf.
Auf meine Frage, wie es unsere GUI-Leute mit Exceptions halten, ob sie welche werfen, ob sie welche fangen, ob sie ihren Code exceptionsicher bauen, bekam ich zur Antwort: Wir scheren uns eigentlich gar nicht um Exceptions, denn das Qt-Framework erledigt das für uns.
-
volkard schrieb:
AmigaOS und AROS kenne ich nicht, glaube Dir aber ganz einfach nicht, daß die den Speicher nicht freigeben. Soweit sind malloc/free kein Problem.
AROS kenne ich nicht, aber AmigaOS kenne ich gut. Hab selbst mal etwas dafür entwickelt was man unter DOS als TSR ("Terminate and Stay Resident") bezeichnet hätte. Daher weiss ich dass man unter AmigaOS keine speziellen Funktionen verwenden muss wenn man Speicher möchte der nach Programmende nicht freigegeben wird -- ganz normal AllocMem/AllocVec und dann ganz normal das Programm beenden und der Speicher bleibt belegt.
Wenn man natürlich die Funktionen der Runtime-Library verwendet, dann kommt es auf die Runtime-Library an. Vermutlich haben die Runtime-Implementierungen der gängigen Compiler für AmigaOS das auch so gehandhabt dass bei Programmende der gesamte CRT-Heap freigegeben wird. Ist aber keine Funktion des OS, und daher irrelevant.
Und nimm bitte selbst weniger Drogen.
ps:
https://en.wikipedia.org/wiki/Memory_leakrunning on an operating system that does not automatically release memory on program termination. Often on such machines if memory is lost, it can only be reclaimed by a reboot, an example of such a system being AmigaOS.[citation needed]
-
@Shade Of Mine
Das static (de)initialization order fisaco ist kein Argument? Klar, ich hätte das alles lange und umständlich in eigenen Worten beschreiben können.Egal. Ich hab' den Beitrag von SeppJ jetzt nochmal gelesen. Ja, hab' ich vermutlich falsch aufgefasst. Bin aber der Meinung dass es auch nicht ganz glücklich formuliert war.
Abgesehen von historischen Betriebssystemen deutet ein "vergessenes" free aber auf einen Logikfehler im Programm hin. Wobei dieser Fehler auch sein kann, dass der Programmierer einfach nicht weiß, wie man es richtig macht. Nichtsdestotrotz ein Fehler.
Der erste Satz alleine wäre (für mich) klar gewesen. Der 2. und 3. sind dann aber so "absolut" formuliert, dass bei mir wirklich der Eindruck entstanden ist dass SeppJ meint es sei immer ein Fehler.
Ja, mein Fehler. Hätte nachfragen sollen.@SeppJ
Siehe oben. War keine Absicht, hab das wirklich falsch verstanden.
Sorry!EDIT:
Und beim 3. mal drüberlesen bin ich wieder bei: nein, ich hab hier nix falsch interpretiert. "Deutet hin auf" ist mMn. eine absolute Aussage und impliziert kein "vielleicht aber auch nicht". Deswegen auch übliche Formulierungen wie "deutet meist auf ... hin" usw. Zumindest verstehe ich die Floskel so.Also, SeppJ. Keine seitenlangen Disclaimer, ein Wort mehr hätte es vermutlich getan. Oder ich muss mein Sprachverständnis reparieren.
-
volkard schrieb:
Tyrdal schrieb:
Unsinn, bei Qt räumt ein parent seine Kinder auf.
Auf meine Frage, wie es unsere GUI-Leute mit Exceptions halten, ob sie welche werfen, ob sie welche fangen, ob sie ihren Code exceptionsicher bauen, bekam ich zur Antwort: Wir scheren uns eigentlich gar nicht um Exceptions, denn das Qt-Framework erledigt das für uns.
Was hat denn Qt mit Exceptions am Hut?
Bzw hier aus der Doku zu 5.5:
Preliminary warning: Exception safety is not feature complete! Common cases should work, but classes might still leak or even crash.
Qt itself will not throw exceptions. Instead, error codes are used.
-
SBond schrieb:
...wann ist ein solcher Speicher wieder verfügbar? Nach Programmende oder erst nach neustart des PCs?
Ich könnte deine Frage beantworten, aber ein Teil meiner Antwort würde dich verunsichern.
-
hustbaer schrieb:
Das static (de)initialization order fisaco ist kein Argument?
Was machst du eigentlich, wenn die Objekte Ressourcen belegen, die kein Speicher sind?
-
SeppJ schrieb:
hustbaer schrieb:
Das static (de)initialization order fisaco ist kein Argument?
Was machst du eigentlich, wenn die Objekte Ressourcen belegen, die kein Speicher sind?
Kurze Antwort: Das OS aufräumen lassen.
Lange Antwort:
Ich versuche statische/globale Objekte bzw. Singletons so weit wie sinnvoll möglich zu vermeiden. Erstmal ganz allgemein, und dann nochmal ganz besonders für Objekte mit nicht-trivialem Destruktor.
Fälle wo ich für mich beschlossen habe dass sowas OK ist sind z.B.
* Berechnete Lookup Tables
=> Nur Speicher => kein Problem
(Wenn die Grösse fix ist könnte man natürlich auch gleich "statischen" Speicher verwenden.)* Lazy-initialization von globalen Objekten
Im Prinzip ähnlich wie die Lookup Tables. Manchmal gibt es z.B. Datenfiles zu laden und zu parsen die man aber nicht jedes mal braucht wenn man Library X verwendet.
Oder so Sachen wie System.Text.Encoding.Utf8, System.Text.StringComparer.Ordinal (sind jetzt Beispiele aus dem .NET Framework, aber das sollte ja egal sein).
=> Auch meist nur Speicher => kein Problem* Logger
Hier gibt es meistens nicht-Speicher Resourcen. Ich hatte bisher nur Files, könnten aber natürlich auch Sockets, RPC-Verbindungen, DB-Verbindungen o.Ä. sein.
Die können alle vom OS weggeräumt werden.
(OK, bei RPC- bzw. DCOM Verbindungen könnte es doof werden, da gibt's zumindest unter Windows z.T. beträchtliche Delays bis die Gegenstelle mitbekommt dass man nicht mehr da ist. Hatte ich aber wie gesagt noch nicht.)
Ein wenig lästig wird es wenn man das Rausschreiben der Logging-Daten asynchron machen will um das Programm nicht unnötig zu bremsen. Dann könnte, wenn man nix dagegen unternimmt, passieren, dass die letzten paar Log-Ausgaben fehlen. Kann man aber auch was dagegen machen. z.B. den Logger vor Programmende flushen und auf "ab jetzt darfst du nicht mehr asynchron loggen" umstellen.Und mehr fällt mir jetzt auf die Schnelle auch gar nicht ein.
Fälle wo es etwas wegzuputzen gibt was das OS nicht wegräumen kann sind mir bisher noch nicht untergekommen. Wird vermutlich auch nicht so schnell passieren, da ich ja wie gesagt sowieso nicht mit Singletons um mich werfe.
Was ich dann machen würde? Mir irgendwas überlegen. Im schlimmsten Fall das Programm doch so umbauen dass die fragliche Resource irgendwie deterministisch freigegeben werden kann. Was natürlich immer irgendwie geht, nur manchmal eben mit einigen groben Nachteilen verbunden ist. Zumindest wenn man Wert auf einfachen und wartbaren Code legt.
