exit(0) prevents execution of destructor ??
Volker Rittner
I've got a little Problem that I won't understud.
I've created an objekt with a method called do_error. The last statement
in this method is exit(0), because the programm should terminate if this
method get's executed. But if I do so, the destructor which writes down
some information to a file don't comes to execution. If I comment exit
(0) out the destructor works. Is this normal? I thought that the
destructor gets in ervery case called....
I'm using KDevelop 1.4 on Suse Linux 7.1.
Thanks for reading,
Volker
jtv
>I've created an objekt with a method called do_error. The last statement
>in this method is exit(0), because the programm should terminate if this
>method get's executed. But if I do so, the destructor which writes down
>some information to a file don't comes to execution. If I comment exit
>(0) out the destructor works. Is this normal? I thought that the
>destructor gets in ervery case called....
Not in the case of exit(), which is a very "dirty" way to terminate the
program in C++. The compiler has no special knowledge of what exit()
means, and sees what amounts to just a normal function call.
So use exit() in C++ only if:
1 things are messed up to the point where a normal cleanup makes no sense; or
2 you *know* there is no destructor cleanup that needs to be done.
You may want to use exceptions instead. A simple trick for this is to
create an exception class not related to std::exception, and catch it only
in the body of main(). Now throwing an object of this type will call all
appropriate destructors as usual, and jump straight to the catch block in
main().
--
Jeroen
Brainbench MVP for C++
http://www.brainbench.com
Phil Staite
too. Suppose you have:
class foo {
public:
void bar();
};
void foo::bar() {
exit(1);
}
foo aGlobalFoo; // file scope
int main() {
foo aLocalFoo;
aLocalFoo.bar();
return 0;
}
Now, if exit() succeeds, then it never returns. If it never returns, then
the stack isn't unwound and locals such as aLocalFoo are never destructed
because the code at the end of the function (main in this case) is never
executed. Global objects, such as aGlobalFoo should be destructed.
Stephen Howe
Volker Rittner <vo...@gmx.de> wrote in message
news:3AB0E068...@gmx.de...
> Hy all,
> I've got a little Problem that I won't understud.
> I've created an objekt with a method called do_error. The last statement
> in this method is exit(0), because the programm should terminate if this
> method get's executed. But if I do so, the destructor which writes down
> some information to a file don't comes to execution. If I comment exit
> (0) out the destructor works. Is this normal? I thought that the
> destructor gets in ervery case called....
Why don't you throw an exception? Further up the execution path, local
objects will have had their destructors called, catch the exception, cleanup
as best you can then call exit (preferably with a non-zero value
(EXIT_FAILURE) as zero traditionally signifies that the program terminated
normally (I think EXIT_SUCCESS conveys this)).
Stephen
Karl Heinz Buchegger
From the standard
<Quote>
3.6 Start and termination
3.6.1 Main function
....
Calling the function
void exit( int )
declared in <cstdlib> (18.3) terminates the program without leaving the
current block and hence without destroying any objects with automatic
storage duration (12.4). If exit is called to end a program during the
destruction of an object with static duration, the program has undefined
behaviour.
</Quote>
You should find other ways to terminate your program. exit()
is ment to be a way you can use, when everything else is
hopeless, eg. your data structure gets completely messed up
so that calling destructors will end in endless chain of exceptions.
--
Karl Heinz Buchegger
kbuc...@gascad.at
Karl Heinz Buchegger
Attila Feher wrote:
>
> It is normal. Exit is C stuff. Try throwing an exception an
> encapsulate your main function in a try block and call exit(0) in the
> catch.
At this point simply return. calling exit() would stop the
dtors of global objects to be run.
Attila Feher
>
> Hy all,
> I've got a little Problem that I won't understud.
> I've created an objekt with a method called do_error. The last statement
> in this method is exit(0), because the programm should terminate if this
> method get's executed. But if I do so, the destructor which writes down
> some information to a file don't comes to execution. If I comment exit
> (0) out the destructor works. Is this normal? I thought that the
> destructor gets in ervery case called....
Volker Rittner
now I'm throwing....
Volker
Ron Natalie
Karl Heinz Buchegger wrote:
>
> Attila Feher wrote:
> >
> > It is normal. Exit is C stuff. Try throwing an exception an
> > encapsulate your main function in a try block and call exit(0) in the
> > catch.
>
> At this point simply return. calling exit() would stop the
> dtors of global objects to be run.
Nope, global objects get destroyed with exit. return out of
main just logically calls exit anyhow.
Alan Donovan
> 3.6 Start and termination
> 3.6.1 Main function
>
> ....
> Calling the function
> void exit( int )
> declared in <cstdlib> (18.3) terminates the program without leaving the
> current block and hence without destroying any objects with automatic
> storage duration (12.4). If exit is called to end a program during the
> destruction of an object with static duration, the program has undefined
> behaviour.
Karl, this has nothing to say about destruction of static objects, only
aurtomatic. My understanding was always that exit causes clean
destruction of them -- however I don't have the standard handy.
Stroustrup
and Ellis concur (ARM, sec 3.4).
IIRC the implementation is often similar to an atexit() hook.
alan
--
Alan Donovan, ARM Research, ARM Ltd. alan.d...@arm.com
Attila Feher
> Nope, global objects get destroyed with exit. return out of
> main just logically calls exit anyhow.
Yeppp. Global objects. I did not read carefully enough...
WW