CODEWITHSUNDEEP
c++c++11exit
Sherwin
Sherwin

Reputation: 857

should we use exit in C++?

According to C++ reference

exit terminates the process normally, performing the regular cleanup for terminating programs.

Normal program termination performs the following (in the same order): Objects associated with the current thread with thread storage duration are destroyed (C++11 only). Objects with static storage duration are destroyed (C++) and functions registered with atexit are called. All C streams (open with functions in ) are closed (and flushed, if buffered), and all files created with tmpfile are removed. Control is returned to the host environment.

Note that objects with automatic storage are not destroyed by calling exit (C++).

as far as i know, when the process terminated, all the storage used by the process are reclaimed, so what's the impact that objects with automatic storage are not destroyed?

Upvotes: 7

Views: 2371

Answers (3)

Cheers and hth. - Alf
Cheers and hth. - Alf

Reputation: 145419

In C++ you should preferably use std::terminate rather than exit or abort to do an orderly fatal error exit, because code that you're using may have installed a terminate handler to do critical cleanup.

The default std::terminate handler calls abort.

The stack is not unwound.

Re

” what's the impact that objects with automatic storage are not destroyed?

Because destructors are not called, cleanup that they might do is not performed. For example, in Windows a console window might become unusable if it has a custom text buffer. Temporary files might be left on disk. Helper processes might not be shut down. And so on.

This must be weighted against the possibility of nasty things happening if general cleanup is attempted, e.g. because an assertion has fired, showing that some fundamental assumption about the process state doesn't hold.

Upvotes: 3

user3995702
user3995702

Reputation:

The problem is the fact not everything you might somehow take ownership of is listed in the standard as getting cleaned up.

For example, many programs and libraries do things like create lock files, start background processes, change system settings, and so on. These may be cleaned up by the OS if you call exit, but they aren't required to be. Failing to release these could have effects ranging from being unable to restart the program (typical of lock files) to total system failure (less likely, but possible in some cases).

True, on-topic anecdote. I used to use OIS, an input library, for my project. Every time I killed my program in the debugger, key repeat was broken system-wide, because OIS 'temporarily' disabled it in Linux. I fixed it by changing settings (and later dumping OIS entirely), but this illustrates very well the sort of issues you might run into calling exit before you have cleaned up your environment yourself.

Upvotes: 7

Mooing Duck
Mooing Duck

Reputation: 66961

If those destructors are not called, their side effects don't happen: Freeing resources in other processes, deleting temporary files outside that folder, flushing non-c stream files, etc etc etc

Upvotes: 8

Related Questions