Simple question about exit(1)

Discussion in 'C++' started by Vicent Giner-Bosch, Jun 18, 2010.

  1. Hello.

    If I do "exit(1)" in any part of my program, does it take into account
    allocated space (instances of objects, and so on) and de-allocate it
    before termining the execution??

    To be more concrete:

    The program defines an ofstream object (for text output), and a new
    object via "new" statement, and then, in the middle of the execution,
    it is possible that an "exit(1)" command arrises, so in that case the
    lines where I "close" the ofstream object and I delete the object
    created with the "new" statement will not be read. Is that fine??

    Actually, this is all about handling exceptions, so, any hint, tip,
    suggested reading...?

    Thank you in advance for your answers!
    Vicent Giner-Bosch, Jun 18, 2010
    #1
    1. Advertising

  2. Vicent Giner-Bosch

    mingze zhang Guest

    On Jun 18, 5:05 pm, Vicent Giner-Bosch <> wrote:
    > Hello.
    >
    > If I do "exit(1)" in any part of my program, does it take into account
    > allocated space (instances of objects, and so on) and de-allocate it
    > before termining the execution??
    >
    > To be more concrete:
    >
    > The program defines an ofstream object (for text output), and a new
    > object via "new" statement, and then, in the middle of the execution,
    > it is possible that an "exit(1)" command arrises, so in that case the
    > lines where I "close" the ofstream object and I delete the object
    > created with the "new" statement will not be read. Is that fine??
    >
    > Actually, this is all about handling exceptions, so, any hint, tip,
    > suggested reading...?
    >
    > Thank you in advance for your answers!


    you don't need to worry anything.

    void exit ( int status );
    Terminate calling process

    Terminates the process normally, performing the regular cleanup for
    terminating processes.

    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.

    The status argument is returned to the host environment.
    mingze zhang, Jun 18, 2010
    #2
    1. Advertising

  3. Vicent Giner-Bosch

    Fred Zwarts Guest

    "Vicent Giner-Bosch" <> wrote in message
    news:
    > Hello.
    >
    > If I do "exit(1)" in any part of my program, does it take into account
    > allocated space (instances of objects, and so on) and de-allocate it
    > before termining the execution??
    >
    > To be more concrete:
    >
    > The program defines an ofstream object (for text output), and a new
    > object via "new" statement, and then, in the middle of the execution,
    > it is possible that an "exit(1)" command arrises, so in that case the
    > lines where I "close" the ofstream object and I delete the object
    > created with the "new" statement will not be read. Is that fine??
    >
    > Actually, this is all about handling exceptions, so, any hint, tip,
    > suggested reading...?


    If your only concern is deallocation of memory,
    then it depends on your operating system environment.
    Most operating systems will deallocate all memory at program exit.

    However, exit is not handled as an exception.
    So, no stack unwinding takes place.
    It is possible that this leaves e.g. files, or databases in an inconsitent state,
    if there are objects on the stack which require proper destruction.
    Static objects, however, are destructed when exit is called.
    This may cause strange behaviour if these destructors rely
    on the stack objects being destructed already.
    Fred Zwarts, Jun 18, 2010
    #3
  4. Vicent Giner-Bosch

    Goran Guest

    On Jun 18, 11:05 am, Vicent Giner-Bosch <> wrote:
    > Hello.
    >
    > If I do "exit(1)" in any part of my program, does it take into account
    > allocated space (instances of objects, and so on) and de-allocate it
    > before termining the execution??


    Why do you want to exit like that? It's not needed and, to the
    contrary of what some people said here, it's not very safe either.

    On a full-fledged OS of today, like Windows/Unix, sure, all OS
    resources will be freed, but what about e.g. your program data? E.g.
    what if you started writing something to some file of yours and
    terminated in the middle? If file OK? Will you be able to recover if
    it's cut in a bad place?

    In other words, you don't do exit(1) as a matter of fact, not in C,
    not in C++.

    Luckily, in C++, you can easily get what you want, which, I guess, is
    to leave all your processing when something really catastrophic
    happen. Here's what you can do:

    In catastrophy.hpp

    extern void catastrophy(int exit_code);

    In catastrophy_impl.hpp

    struct catastrophy_exception
    {
    catastrophy_exception(int exit_code): _exit_code(exit_code)
    {
    }
    const int _exit_code;
    };

    In catastrophy_impl.cpp

    void catastrophy(int exit_code)
    {
    throw catastrophy_exception(exit_code);
    }

    In main.cpp:

    #include "catastrophy_impl.hpp"

    int main(...)
    {
    try
    {
    workworkwork();
    return 0;
    }
    catch(catastrophy_exception whoops)
    {
    return whoops._exit_code;
    }
    }

    The above is a near-equivalent to exit(), but has a major advantage:
    stack unwind happens. So as long as your code cleans-up properly in
    case of exceptions (and that's what you should have anyhow), it's much
    better.

    In any other file, include catastrophy.hpp and call catastrophy() if
    you need it. Don't ever try to catch catastrophy_exception, and don't
    ever catch(...) without a rethrow. In fact, don't ever write
    catch(...). Given exception handling tools we have today in C++,
    catch(...) {} is a bug, even if it has a throw in it.

    Given that you are asking in light of exceptions... You probably need
    to learn how to write exception-safe code. That goes for C++ as well
    as for any language that uses exceptions. That's tough, but
    rewarding :).

    Note: in files where you don't include catastrophy_impl.hpp, you can't
    catch catastrophy_exception, that just won't compile, obvoiusly. So
    don't include it, include only catastrophy.hpp!

    Goran.
    Goran, Jun 18, 2010
    #4
  5. Vicent Giner-Bosch <> wrote:
    > If I do "exit(1)" in any part of my program, does it take into account
    > allocated space (instances of objects, and so on) and de-allocate it
    > before termining the execution??


    I wonder if there is any operating system in existence which is newer
    than 30 years and which doesn't clean up the memory used by a program
    which exited abruptly. There might have been some experimental single-user
    operating systems in the 60's which needed to be rebooted after each
    program execution in order to reset the memory usage (this assuming that
    you could even return to the OS at all from apps).

    I don't think even MS-DOS 1.0 "leaked" any memory after a program
    terminated and it returned to the command line.

    > The program defines an ofstream object (for text output), and a new
    > object via "new" statement, and then, in the middle of the execution,
    > it is possible that an "exit(1)" command arrises, so in that case the
    > lines where I "close" the ofstream object and I delete the object
    > created with the "new" statement will not be read. Is that fine??


    No OS I know of would fail to properly free the file handles which were
    requested by a process which then failed to explicitly release them. Such
    an OS would be rather useless (because, after all, even bug-free programs
    can sometimes be terminated abruptly by external means).

    The problems happen if your program itself needs to clean up. One typical
    case is if it uses some temporary files which it should remove before it
    terminates. Since these are just regular files, the OS won't do anything to
    them. They are just files which the program created. If they should be
    removed, the program has to do it. Naturally if you do a exit(1), those
    files will not be removed because the program will be terminated right
    there and no destructors will be called. (You could hook a cleaning
    function with the atexit() standard function, but in C++ there usually
    are better ways to do this.)
    Juha Nieminen, Jun 21, 2010
    #5
  6. Vicent Giner-Bosch

    James Kanze Guest

    On Jun 18, 7:13 pm, Paavo Helde <> wrote:
    > Christian Hackl <> wrote in news:hvffg9$e0h$1
    > @news.eternal-september.org:
    > >http://www.cplusplus.com/reference/clibrary/cstdlib/exit/


    > > Actually, I don't know why they claim that "temporary files"
    > > are deleted. That's a very misleading statement. AFAIK,
    > > neither Windows nor Unix/Linux can handle filesystems that
    > > have a concept of temporary files that is not enforced only
    > > by convention.


    > In Windows one can use the FILE_FLAG_DELETE_ON_CLOSE flag for
    > CreateFile() to have the file deleted on program exit. In
    > Linux/Unix one can achieve the same effect by opening a file,
    > then immediately unlink()-ing all references to it from the
    > disk directories. However, when one talks about "temporary
    > files" one probably means something else.


    But these solutions don't work for standard streams, or at
    least, the one for Windows doesn't (because the filebuf never
    uses this flag when it does CreateFile).

    Practically, too, it's not rare to want to close a temporary
    file, then reopen it later.

    It's possible to make this work, more or less, by registering
    the temporary files with an object with static lifetime, which
    deletes them in its destructor. In the case of Windows, you
    still have to ensure that the file is closed first. Which
    brings us to the one big problem with exit---it doesn't call the
    destructors of local objects. So if you write something like:

    void f()
    {
    std::string tmpname(getTempFileName());
    std::fstream tmp(name.c_str());
    TempFileManager::instance().register(tmpname);
    // ...
    if (something)
    exit(1);
    // ...
    }

    , the temp file will not get deleted.

    One convention that I've used at times is that main() is always:

    main(...)
    {
    try {
    // actual code...
    return errorStatus;
    } catch ( int returnCode ) {
    return returnCode;
    }
    }

    Then, instead of calling exit(EXIT_FAILURE), you "throw
    EXIT_FAILURE".

    --
    James Kanze
    James Kanze, Jun 22, 2010
    #6
  7. Vicent Giner-Bosch

    Jorgen Grahn Guest

    On Mon, 2010-06-21, Juha Nieminen wrote:
    > Vicent Giner-Bosch <> wrote:
    >> If I do "exit(1)" in any part of my program, does it take into account
    >> allocated space (instances of objects, and so on) and de-allocate it
    >> before termining the execution??

    >
    > I wonder if there is any operating system in existence which is newer
    > than 30 years and which doesn't clean up the memory used by a program
    > which exited abruptly. There might have been some experimental single-user
    > operating systems in the 60's which needed to be rebooted after each
    > program execution in order to reset the memory usage (this assuming that
    > you could even return to the OS at all from apps).
    >
    > I don't think even MS-DOS 1.0 "leaked" any memory after a program
    > terminated and it returned to the command line.


    You don't have to go back to primitive things like DOS. AmigaDOS
    (1985--1995--?) was a rather Unix-like multitasking OS, but did not
    keep track of which process allocated memory or opened files.

    The standard C library (shipped by your compiler vendor, not with the OS)
    *did* have tracking of malloc()ed memory and open FILE* streams, but
    (a) I'm not sure what loopholes there were in those schemes and (b)
    many or most people rejected the standard library due to percieved
    overhead.

    I suspect contemporary OSes for embedded devices do it like that too,
    but I only have some experience with VxWorks and OSE, and in both cases
    I've used processes/tasks defined to always be running and never to be
    terminated or restarted ...

    ....
    > No OS I know of would fail to properly free the file handles which were
    > requested by a process which then failed to explicitly release them. Such
    > an OS would be rather useless (because, after all, even bug-free programs
    > can sometimes be terminated abruptly by external means).


    The AmigaDOS solution was simply not to have external abrupt
    terminations, in the style of Ctrl-C or kill -9. That was the worst
    effect of not having resource tracking, IMO. Other than that, I
    thought at the time that it worked really well.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Jun 27, 2010
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?U2FuZHk=?=

    Code to Exit Web App and Exit Internet Explorer

    =?Utf-8?B?U2FuZHk=?=, Aug 3, 2005, in forum: ASP .Net
    Replies:
    7
    Views:
    7,878
    =?Utf-8?B?U2FuZHk=?=
    Aug 5, 2005
  2. Joe Smith
    Replies:
    4
    Views:
    65,794
    sandeep1976
    Nov 8, 2006
  3. Replies:
    2
    Views:
    443
    Jeff Epler
    May 31, 2005
  4. QQ
    Replies:
    5
    Views:
    506
    Jonathan Adams
    May 10, 2005
  5. Vicky

    Difference between exit(0) & exit (1)

    Vicky, Aug 8, 2006, in forum: C Programming
    Replies:
    6
    Views:
    700
    Kenneth Brody
    Aug 8, 2006
Loading...

Share This Page