exit() ??

[Gast]

vista schrieb:

ichduersieeshihi schrieb:

Leert exit(1) z.B. zuvor allokierten Speicher...?

exit() macht das nicht, aber normalerweise gibt dein betriebsystem sämtlichen speicher des programms wieder frei, wenn es sich mit exit() selber killt.

Schöner wäre es natürlich trotzdem alles aufzuräumen bevor man exit() aufruft.

[Pfuscher_Mundhalten!]

Ich glaube TacTX wollte damit folgendes ausdrücken.....

exit() terminiert den Prozess erst NACH dem aufräumen! = ANSI-standard.

Im Gegensatz zu _exit() - MAN BEACHTE DEN UNDERSCORE! - der ohne Aufräumen terminiert. Allerdings ist _exit() nicht ANSI-standard

[CStoll]

Nein, vor allem daß man: exit nicht alles aufräumt, was aufzuräumen ist. Vor allem (OK, das ist mehr für C++ interessant) ruft es nicht die Destruktoren von Heap-Objekten auf (afaik noch nichtmal die von Stack-Objekten).

[LordJaxom]

CStoll schrieb:

Nein, vor allem daß man: exit nicht alles aufräumt, was aufzuräumen ist. Vor allem (OK, das ist mehr für C++ interessant) ruft es nicht die Destruktoren von Heap-Objekten auf (afaik noch nichtmal die von Stack-Objekten).

Die Destruktoren von Heap-Objekten werden doch sowieso nicht automatisch aufgerufen. Damit bleiben nur die Stack-Objekte (und das bedingt durch das fehlende Abarbeiten des Stacks, wobei ja Stack-Objekte zerstört werden).

[vista]

CStoll schrieb:

(afaik noch nichtmal die von Stack-Objekten).

ich glaube, noch nicht mal die von globalen objekten.
wär' ja auch mist - wenn einer eine endlosschleife im destruktor hat, würde 'exit' hängenbleiben.

[Heap_und_Stack_fest]

Wäre ja auch unmöglich einen Destruktor für eine unbestimmte Größe einer Struktur aufzurufen.

[CStoll]

Wer sagt denn, daß irgendwas zur Laufzeit unbestimmte Größe hat?

[vista]

Heap_und_Stack_fest schrieb:

Wäre ja auch unmöglich einen Destruktor für eine unbestimmte Größe einer Struktur aufzurufen.

das hat ja nichts mit der grösse zu tun. so'n destruktor ist einfach nur eine funktion, die automatisch aufgerufen wird.

c++ programm welches sich aufhängt:

class C
{
  public: ~C() {for(;;);}
} c;

int main()
{
    // mache nichts
}

[Heap_und_Stack_fest]

Ich meinte "unmöglich" im Sinne von "nicht sehr sinnvoll", nicht wie vielleicht angenommen im Sinne von "nicht möglich".

Aber das Objekte im Heap zur Laufzeit unbestimmte Größe haben entnehme ich hieraus:

Die Erklärung zu "Heap" lt. MS VC++ 6.0

Auch freier Speicher. Ein Bereich des Arbeitsspeichers, der für ein Programm zur temporären Speicherung von Datenstrukturen reserviert ist, deren Existenz oder Größe nicht festgelegt werden können, bevor das Programm ausgeführt wird. Das Programm kann freien Speicher vom Heap anfordern, um solche Elemente abzulegen, ihn bei Bedarf verwenden und den Arbeitsspeicher später wieder freigeben.
ENDE der Erklärung lt. oben genannter Quelle!

[LordJaxom]

1. Heap-Objekte werden generell nur dann zerstört, wenn der Programmierer dies explizit anfordert (durch delete).
2. Dann ist auch nichts unbestimmt, denn delete weiss sowohl welchen Destruktor es aufrufen muss (anhand des Typs) und wieviel Speicher freizugeben ist (anhand der Größe des Typs). Und selbst bei Arrays weiss es wieviele Objekte sich dort befinden.
3. "Deren Existenz oder Größe nicht festgelegt werden können bevor das Programm ausgeführt wird" impliziert für mich dass die Existenz oder Größe sehr wohl feststehen kann während das Programm ausgeführt wird

[Heap_und_Stack_fest]

Der 3. Punkt stimmt schon wie du das schreibst, aber in jenem Fall wird das Objekt an den Stack übergeben - und ist somit für den Heap Geschichte...

Bestenfalls könnte man also mit atexit() noch Destruktorroutinen aufrufen die den Heap säubern aber wie CStoll schon gepostet hat ist es für exit() schlichtweg nicht möglich.

Ich glaube mich auch daran zu erinnern irgendwo gehört und gelesen zu haben das delete nur in verbindung mit new verwendet werden soll.

[LordJaxom]

Heap_und_Stack_fest schrieb:

Der 3. Punkt stimmt schon wie du das schreibst, aber in jenem Fall wird das Objekt an den Stack übergeben - und ist somit für den Heap Geschichte... [...]
Ich glaube mich auch daran zu erinnern irgendwo gehört und gelesen zu haben das delete nur in verbindung mit new verwendet werden soll.

Ja, mit new legt man auf dem Heap Objekte an, deren Existenz oder Größe zur Compilezeit noch nicht feststeht. Diese landen auf dem Heap, und man muss sie mit delete löschen. Dass das bekannt ist war meine Annahme, deshalb kann ich den ersten Satz oben nicht so recht einordnen... new -> heap -> delete... Wieso ist der Heap damit Geschichte?

[heap_und_stack_fest]

Im generellen ist das auch korrekt aber für die Funktion "exit()" ist nicht der Heap brisant sondern der Stack, darum nützt mir new() und delete() in diesem Fall nicht so ganz um "aufzuräumen". Wie schon zuvor gepostet, bestenfalls mit "atexit()".

Aber wie auch immer, new bzw. delete ist ja kein ANSI C sondern C++

[vista]

heap_und_stack_fest schrieb:

Im generellen ist das auch korrekt aber für die Funktion "exit()" ist nicht der Heap brisant sondern der Stack

exit() interessiert weder der heap noch der stack
es werden zwar noch die funktionen aufgerufen, die man mit 'atexit()' registriert hat, aber beim beenden des programms sind heap und stack ebenfalls *weg*
(jedenfalls ist es unter windows so)

[Heap_und_stack_fest]

Exit leistet aber sehr wohl noch ein gewisses Maß an Aufräumarbeit - im Stack - nicht aber im Heap...

[vista]

Heap_und_stack_fest schrieb:

Exit leistet aber sehr wohl noch ein gewisses Maß an Aufräumarbeit - im Stack - nicht aber im Heap...

warum sollte 'exit' etwas mit dem stack machen, wenn der sowieso nach beendigung des programms aufgelöst wird?

[Heap_und_stack_fest]

CStoll hat in einem Thread zuvor einen Hyperlink zu exit() (openBSD-Doku) gelegt wo die Antwort auf deine Frage steht...es ist halt so

[vista]

meinst du das?

First, all functions registered by calls to atexit are executed in the reverse order of their registration. Then, all streams are closed and the temporary files deleted, and finally the control is returned to the host environment.

naja, bis auf den ersten satz macht den rest das OS (gilt jedenfalls unter win)

[Heap_und_Stack_fest]

...returned to the host environment...

ist nicht immer unbedingt das OS...

[Gast]

Heap_und_Stack_fest schrieb:

...returned to the host environment...

ist nicht immer unbedingt das OS...

Ermmm, was dann?