...wenn free oder delete vergessen wird
-
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.
-
hustbaer schrieb:
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?
[Lange Antwort]
Das war eigentlich eher als rhetorische Frage gemeint, sorry falls das nicht richtig rüber kam.
-
Nein, kam es gar nicht.
Und ich verstehe auch nach diesem Hinweis noch nicht was du damit zum Ausdruck bringen wolltest. Denn irgendwas will man ja auch mit einer rhetorischen Frage kommunizieren -- sonst würde man schliesslich einfach gar nix schreiben/sagen.
-
Dass es, wenn es schon kein Logikfehler ist, doch etwas ist, was man möglichst vermeiden sollte, wenn es geht. Und manche Sachen gehen eben gar nicht fehlerfrei, wenn dieser Fall vorliegt.
-
Achso. Ja. Das sollte man möglichst.
