break; langsamer als exit() ?

-.- Du glaubst es nicht oder?

Hier ein Bild aus dem Debugger meiner IDE: http://www7.pic-upload.de/09.11.12/cej3g1y7jr5o.png

na prima. dann hab ich mich getäuscht... soll ja auch mal vorkommen

Ich kannte das von Opera (inzwischen passiert das nicht mehr). Wegen Flash und anderem Krams hatte Opera 2GB RAM auf einem Rechner belegt, der nur 1GB hatte. Da es aber auf die Festplatte ausgelagert wurde hat sich das nicht sonderlich auf die Performance ausgewirkt. Wenn man aber Opera geschlossen hat, dann hat er die ganzen 2 GB stückweise reingeswappt, nur um sie freizugeben. Das hat etwa eine Minute gedauert und ich hätte mir gewünscht, dass die einfach exit() aufrufen wenn man das Fenster schließt statt aus der main zurückzukehren.

oO

auf der anderen seite machst du das auffinden von memleaks fast unmöglich, weil ein exit() nichts aufräumt und der counter dann sicher nicht auf 0 steht. außer das programm ist klein.

wie dumm von mir, wir haben ja schon geklärt, dass c++'ler keine memleaks produzieren

_matze

Und wenn das Programm was systemglobales (z.B. Mutex) erzeugt, der dann wegen exit nicht wieder aufgeräumt wird? Oder wenn man auf einem Betriebssystem arbeitet, dass den Speicher eines Prozesses nicht automatisch bei Beenden freigibt? Die saubere Lösung ist return, Punkt.

Sone

.

hustbaer

suung schrieb:

SomeoneWithAQuestion schrieb:

Ich dachte, dass das break; statement in dem Fall einfach - in Assembler übersetzt - ein jmp hinter den Körper der while-schleife ist.

break; entspricht einem Short Jmp. Opcode: 0xEB

Blah
break; entspricht dem was der Compiler draus macht. Das kann alles mögliche sein.

hustbaer

_matze schrieb:

Und wenn das Programm was systemglobales (z.B. Mutex) erzeugt, der dann wegen exit nicht wieder aufgeräumt wird? Oder wenn man auf einem Betriebssystem arbeitet, dass den Speicher eines Prozesses nicht automatisch bei Beenden freigibt? Die saubere Lösung ist return, Punkt.

Je nach System ist das vollkommen unproblematisch.
Und die üblichen Systeme geben den Mist von Programmen frei die sich einfach so verabschieden.
System-Resourcen aufräumen ist also meistens kein Problem.

_matze

hustbaer schrieb:

_matze schrieb:

Und wenn das Programm was systemglobales (z.B. Mutex) erzeugt, der dann wegen exit nicht wieder aufgeräumt wird? Oder wenn man auf einem Betriebssystem arbeitet, dass den Speicher eines Prozesses nicht automatisch bei Beenden freigibt? Die saubere Lösung ist return, Punkt.

Je nach System ist das vollkommen unproblematisch.
Und die üblichen Systeme geben den Mist von Programmen frei die sich einfach so verabschieden.
System-Resourcen aufräumen ist also meistens kein Problem.

Ist mir schon bewusst. Das war eher theoretisch betrachtet. Willst du hier eine Lanze für die exit-Variante brechen?

hustbaer

_matze schrieb:

Ist mir schon bewusst. Das war eher theoretisch betrachtet. Willst du hier eine Lanze für die exit-Variante brechen?

In gewisser Weise ja.
Es gibt Fälle wo ich es für einen Fehler halte alles sauber aufzuräumen.
Spontan fallen mir drei ein.

Manchmal ist es sehr schwierig die korrekte Reihenfolge hinzubekommen in der Dinge freigegeben werden müssen. z.B. wenn man mit Singletons arbeitet. Ich bin zwar überhaupt kein Fan von Singletons (u.A. deswegen), aber es gibt auch Fälle wo man sich durch den Verzicht auf Singletons das Leben unnötig schwer macht. Manche Dinge ganz bewusst bei Programmende nicht freizugeben kann daher eine durchaus akzetable Lösung sein. Natürlich muss man aufpassen dass diese nicht-freigegebenen Dinge nichts wichtiges in ihrem Cleanup-Code machen. Wenn z.B. ein File offen ist, und der Cleanup-Code noch schnell gecachte Daten rausschreibt, dann sollte er auch aufgerufen werden. Wenn nur das File-Handle geschlossen wird kann man aber gerne darauf verzichten.
Bei bestimmten Fehlern sollten mMn. keine Destruktoren aufgerufen werden. Nämlich dann wenn Invarianten verletzt wurden oder sonstige "assert-Artige" Fehler auftreten. Also Dinge die "eigentlich nicht passieren dürfen". Sich dann darauf zu verlassen dass der ganze Cleanup-Code nichts schlimmer macht als es bereits ist, ist mMn. oft ein Fehler.
Es gibt das Konzept der sog. "crash only software". Wenn man seine Programme darauf auslegt, dass es nie irgendetwas gibt was beim Beenden noch schnell gespeichert/modifiziert/finalisiert/... werden müsste, dann besteht auch kein Grund alle Komponenten einzeln niederzufahren/aufzuräumen etc. In dem Fall kann man ruhig einfach exit() oder gar TerminateProcess() machen. Während des Entwickelns sollte man vermutlich trotzdem einen sauberen Shutdown-Pfad drinnen haben, z.B. um Leaks zu finden bzw. den Cleanup-Code von Komponenten zu testen (der ja trotzdem benötigt wird wenn bestimmte Komponenten während der Laufzeit aufgeräumt werden müssen).