Mir wurde beigebracht, bei Programmende dafür zu sorgen, dass jeder, vom Prozess reservierter Speicher, manuell wieder freigegeben werden muss.

Nur frage ich mich warum dies weiterhin so propagiert wird.
Denn jedes moderne Betriebssystem macht doch den Heap des Prozesses bei Beendigung sowieso 100%ig zu Nichte.
Warum also noch so einen Aufwand betreiben?

Danke für eure Aufklärung!

wenn sichergestellt ist, dass es sich wirklich um das Ende des Programms handelt, stimmt das schon ... allerdings weiß man meistens nur, dass die aktuelle Funktion oder der Lebenszyklus des aktuellen Objekts verlassen wird.
Und wenn das nutzende Programm eine Serveranwendung ist, die nur alle 6 Monate mal runtergefahren wird, passt das schon nicht mehr.

Ich sage mal so: Nur in den allerseltensten Fällen werden Ressourcen im main() reserviert und dort freigegeben und nur da wäre das Weglassen von deletes halbwegs zuverlässig.

Ein ganz anderes Problem: Wer weiß, welche Ressourcen im Dtor noch so aufgeräumt werden ? Da könnten ganz schnell unangenehme Seiteneffekte auftreten. Fachliche wie ein DB-Rollback, weil im DTor ein Auto-Commit implementiert ist. Technische wie die Blockade einer Netzwerkressource, weil sie im System einen Timeout von 10 Minuten konfiguriert hat.....

Langer Rede kurzer Sinn: Einfach sauber bleiben ! Kostet nicht viel und spart viel Ärger.

Gruß,

Simon2.

Mir geht es aber wirklich nur um die Frage ob es (heutzutage) irgend einen Grund geben könnte, Speicher explizit vor exit() freizugeben.
In dem (Win95-Era) Projekt woran ich gerade arbeite werden vor Programmende extra Listen usw. durchgegrast und deren Speicher freigegeben - und das wirklich nur der Speicherfreigabe wegen.

Daher die Frage ob es irgend einen Sinn aus Sicht der Speicherverwaltung noch dafür gibt.

Daher die Frage ob es irgend einen Sinn aus Sicht der Speicherverwaltung noch dafür gibt.

Ist ohne Sinn!

Ich schmeiße doch meine Kaugummipapiere auch nicht auf die Straße, obwohl ich genau weiß, dass die Stadtreinigung hier sowieso sauber macht. Gut, schlechter Vergleich.

Ich schmeiße doch meine Kaugummipapiere auch nicht auf die Straße, obwohl ich genau weiß, dass die Stadtreinigung hier sowieso sauber macht. Gut, schlechter Vergleich.

Ja. Das OS tut ja nicht das, was du ohnehin machen würdest. Vor Programmende aufzuräumen ist ungefähr vergleichbar damit, nochmal das Treppenhaus zu fegen bevor die Abrißbirne einschlägt. OK, meine Tante würde das wahrscheinlich machen

Vor Programmende aufzuräumen ist ungefähr vergleichbar damit, nochmal das Treppenhaus zu fegen bevor die Abrißbirne einschlägt.

den muss ich mir merken

Konrad Rudolph schrieb:

Ich schmeiße doch meine Kaugummipapiere auch nicht auf die Straße, obwohl ich genau weiß, dass die Stadtreinigung hier sowieso sauber macht. Gut, schlechter Vergleich.

Ja. Das OS tut ja nicht das, was du ohnehin machen würdest. Vor Programmende aufzuräumen ist ungefähr vergleichbar damit, nochmal das Treppenhaus zu fegen bevor die Abrißbirne einschlägt. OK, meine Tante würde das wahrscheinlich machen

Da würde ich dann aber auch zum stylishen Programmende mittels

throw;

raten.

*SCNR*

Grüsse

*this

Da würde ich dann aber auch zum stylishen Programmende mittels

throw;

raten.

wie wärs mit:

exit(0);

oder, noch lustiger:

asm hlt;

Gast++ schrieb:

Da würde ich dann aber auch zum stylishen Programmende mittels

throw;

raten.

wie wärs mit:

exit(0);

oder, noch lustiger:

asm hlt;

Was sind denn das für Stilblüten?
SO macht man das:

__asm {
    mov cr0,42
}
// This is how REAL programmers do it!

Grüsse

*this

SO macht man das:

DAS ist aber nicht portabel :p

Schon klar, dass wenn benötigt, z.B. die Auflösung eines Objekts aus funktionellen Gründen implementiert sein muß....

Das bedeutet also, dass Du Dir genau die Implementierung aller direkt und indirekt genutzten Klassen ansehen möchtest, in der Hoffnung, festzustellen, ob sie "funktionelle Auflösungsgründe" haben ... und Dir dann ein paar deletes zu sparen ?
Wäre mir irgendwie zu lästig und ich sehe da wenig Vorteil drin (mal ganz davon abgesehen, dass das in der nächsten Version dieser Objekt schon anders sein kann).

Denk dran: Ohne delete kein Dtor von Heapobjekten und ohne return oder gefangene Exception kein Dtor von Stackobjekten .... irgendwie sehe ich nicht, wo das als Standardverhalten gewinnbringend wäre. Das "Scopeverhalten" hilft mir in der Designphse, mir gründlich Gedanken über Ownership und Abhängigkeiten zu machen - Gedanken, die sich im Gesamtdesign bezahlt machen (nicht nur durch Aufruf der Dtoren).

Gruß,

Simon2.

Gast++ schrieb:

SO macht man das:

DAS ist aber nicht portabel :p

LOL

Einen Bolzen hab ich noch:
So konnte man früher mit dem gcc mal ekegant (und portabel) die Tür schliessen:

class A {
public:
	virtual void foo() = 0;
	A() {foo();};
};

class B : public A {
public:
	virtual void foo() {};
	B() {};
};

B b;

Ja, da guckst Du: "Pure virtual function call" - so ne Exception kriegt nicht jeder hin!

Hab hier grad keinen gcc zum Testen
- [EDIT] Müll [/EDIT]

Grüsse

*this

EDIT: Der MSVC gibt sogar nen Linkerfehler, weil er im Ctor von A garnicht versucht über die vtable zu gehen. Also sucht er nach A::foo(), welches es nicht gibt. Schlauer Compiler

Vor Programmende aufzuräumen ist ungefähr vergleichbar damit, nochmal das Treppenhaus zu fegen bevor die Abrißbirne einschlägt. OK, meine Tante würde das wahrscheinlich machen

Deine Tante ist mir sympathisch.

Ne im Ernst: Das würde ja bedeuten, dass man eine Sonderbehandlung für solche Variablen einführen müsste, die bis zum Programmende existieren. Denn bei allen anderen Variablen muss man sich ja auch darum kümmern, dass sie ordnungsgemäß entsorgt werden. Und andere unverwaltete Ressourcen, also z.B. Grafik-Handles etc. müsste man auch weiterhin selbst freigeben, weil dies das Betriebssystem eben nicht unbedingt übernimmt.

=> Diese Sonderbehandlung für ganz gewisse Variablen ist auf jeden Fall sehr viel mehr Aufwand, und damit potentiell fehleranfälliger, als einfach jede Ressource ordnungsgemäß zu entsorgen.

Und andere unverwaltete Ressourcen, also z.B. Grafik-Handles etc. müsste man auch weiterhin selbst freigeben, weil dies das Betriebssystem eben nicht unbedingt übernimmt.

doch, macht es.
das OS meldet sogar netzwerkverbindungen bei der gegenstelle ab, wenn dein programm abraucht.
kritisch wird's vielleicht bei nichtflüchtigen sachen wie temporäre dateien und registry-einträge o.ä. die bleiben natürlich erhalten.

Konrad Rudolph schrieb:

Und andere unverwaltete Ressourcen, also z.B. Grafik-Handles etc. müsste man auch weiterhin selbst freigeben, weil dies das Betriebssystem eben nicht unbedingt übernimmt.

doch, macht es.

Ich weiß nicht, ob es ein Bug oder by design ist, aber Windows gibt definitiv nicht immer alle GDI-Handles frei. Ich weiß nicht, auf welche Versionen das zutrifft aber das Verhalten ließ sich recht einfach reproduzieren. Hier musste man wirklich manuell nacharbeiten.

Der Speicher sollte auf jeden Fall freigegeben werden. Es gibt noch andere Plattformen als BSD, Linux und Windows auf x86ern oder ähnlichem.
Nehmen wir z.B. DSP's. Da gibt es (meistens) kein OS, welches irgendwas hinter einem her räumt. Wohl aber Frameworks, die Prozesse in definierter Reihenfolge abarbeiten. Wenn so ein Prozess, aus welchen Gründen auch immer, terminiert, muss der Speicher freigegeben werden.

diese prozesse laufen aber nicht in einer sandbox wie z.b. windows user-mode prozesse. wenn da einer mist baut, dann leidet das ganze system darunter. es reicht ja schon, wenn eine globalen speicherverwaltung benutzt wird und ein prozess regelmässig free oder delete auslässt.

Tachyon schrieb:

Gibt noch andere (bessere) Beispiele, auf jeden Fall sollte man sich da nicht auf das OS verlassen.

ja, die alten windosen wie windoofs 3.11, 95, 98, me.
die waren sowas von schlecht...

Konrad Rudolph schrieb:

Ich weiß nicht, ob es ein Bug oder by design ist, aber Windows gibt definitiv nicht immer alle GDI-Handles frei.

das war bei den alten 16-bittigen wins der fall (siehe oben)

Konrad Rudolph schrieb:

Und andere unverwaltete Ressourcen, also z.B. Grafik-Handles etc. müsste man auch weiterhin selbst freigeben, weil dies das Betriebssystem eben nicht unbedingt übernimmt.

doch, macht es.
das OS meldet sogar netzwerkverbindungen bei der gegenstelle ab, wenn dein programm abraucht....

Oho, das würde ich aber nicht so allgemein sagen. Auf unseren AIX-Maschinen mussten wir extra (für die MQ-Verbindung) einen (undokumentierten) keepalive-Parameter setzen - ansonsten schlug ein Standard Timeout von 2 Stunden zu, bevor das kommunzierende System etwas merkte.
Auch die Standard-TCP-Verbindungen hatten untragbare Timeouts (die aber teilweise von anderer Infrastruktur auf der Maschine gefordert wurden) ...

Es bleibt dabei: Alle anderen Maßnahmen bedürfen mehr Aufwand an Prüfung, Umsetzung, Testen als ein delete-Statement...

Gruß,

Simon2.

Oho, das würde ich aber nicht so allgemein sagen. Auf unseren AIX-Maschinen mussten wir extra (für die MQ-Verbindung) einen (undokumentierten) keepalive-Parameter setzen - ansonsten schlug ein Standard Timeout von 2 Stunden zu, bevor das kommunzierende System etwas merkte.

und was sagt uns das? AIX taugt nix!
wieso benutzt ihr undokumentierte parameter? das ist ja erst richtig schlechter stil
btw: ein popeliges windows bekommt es doch auch hin, ein RST zu schicken, wenn das programm abgestürzt ist.

...
wieso benutzt ihr undokumentierte parameter? ...

Ganz einfach: Empfehlung vom Hersteller.
Übrigens war es ein Parameter der MQSeries-Software und nicht vom AIX, der da gesetzt werden musste und AIX haben wir nunmal von unserer Firma als Standard aufgedrückt bekommen ... da hilft auch kein Lamentieren (zumal Windowsserver definitiv nicht das geboten hätten, was wir mit den AIX-Servern machen).

Ist aber letztlich auch vollkommen egal, weil immer noch nicht klar ist, warum man sich hier von Möglichkeiten/Schwächen/Eigenarten des Betriebssystems abhängig machen sollte, wenn es eine definierte, sichere und unaufwändige Standardtechnik gibt ?
Bislang wurden hier ein Haufen Nachteile und nicht ein Vorteil davon genannt.
Wir können noch 100 weitere Threadseiten mit der Diskussion verbringen, für welche Nachteile es evtl. bei diesem oder jenem OS eine "Umschiffung" gäbe, aber ohne "Aufstockung der Pro-Seite" wird das Fazit dasselbe bleiben...

Gruß,

Simon2.

Ist aber letztlich auch vollkommen egal, weil immer noch nicht klar ist, warum man sich hier von Möglichkeiten/Schwächen/Eigenarten des Betriebssystems abhängig machen sollte, wenn es eine definierte, sichere und unaufwändige Standardtechnik gibt ?

na, ganz einfach: warum dinge doppelt erledigen (stichwort 'abrissbirne')?
aber teilweise gebe ich dir recht: irgendwie muss man sich immer darauf verlassen, dass das eine oder andere funktioniert. redundanz bring auch mehr sicherheit.

...
na, ganz einfach: warum dinge doppelt erledigen (stichwort 'abrissbirne')?...

Weil man sich offensichtlich nicht darauf verlassen kann, dass es wirklich jemand an meiner Stelle erledigt (bzw. dass die 'Abrissbirne' exakt den gewünschten Effekt hat wieder 'Staubsauger' ) !
Und "Doppelt gemoppelt" wäre es sowieso nicht, weil das Betriebssystem ja keine bereits abgebauten Ressourcen erneute abbauen würde - das schlägt ja sowieso erst zu, wenn meinem Programm die Kontrolle entglitten ist ...

Gruß,

Simon2.