return vs exit

Discussion in 'C++' started by John Black, Sep 8, 2004.

  1. John Black

    John Black Guest

    Hi,
    I wonder what is the difference between ending the main() with and
    without exit(0)?

    My code is like this flow,

    class ClassA{
    ClassB* cb;

    int toExit();

    public:
    ~ClassA();
    ... constructors and all other API...

    }

    ClassA::~ClassA(){
    this->toExit();
    }

    ClassA::toExit(){
    if (cb != NULL){
    delete cb;
    cb = NULL;
    }
    }

    int main(int argc, char** argv){
    ClassA ca;

    ... some operation ...

    return 0;
    }

    Then the program exits with a core dump, in debugger I can see that
    the core dump comes from "}" after "return 0;" in main() and "delete cb"
    in ClassA::toExit().

    In purify it says some FMR, Free Memory Read errors.

    Then I replace "return 0" with "exit(0)" in main(), everything is
    fine: there is no core dump and purify FMR errors are gone!

    What's the trick here?

    Thanks.
    John Black, Sep 8, 2004
    #1
    1. Advertising

  2. John Black

    Phlip Guest

    John Black wrote:

    > I wonder what is the difference between ending the main() with and
    > without exit(0)?
    >
    > My code is like this flow,
    >
    > class ClassA{
    > ClassB* cb;
    >
    > int toExit();
    >
    > public:
    > ~ClassA();
    > ... constructors and all other API...
    >
    > }


    What does your constructor do to cb? Does it ever point to a 'new'ed heap
    object?

    >
    > ClassA::~ClassA(){
    > this->toExit();
    > }
    >
    > ClassA::toExit(){
    > if (cb != NULL){
    > delete cb;
    > cb = NULL;
    > }
    > }
    >
    > int main(int argc, char** argv){
    > ClassA ca;
    >
    > ... some operation ...
    >
    > return 0;
    > }
    >
    > Then the program exits with a core dump, in debugger I can see that
    > the core dump comes from "}" after "return 0;" in main() and "delete cb"
    > in ClassA::toExit().
    >
    > In purify it says some FMR, Free Memory Read errors.
    >
    > Then I replace "return 0" with "exit(0)" in main(), everything is
    > fine: there is no core dump and purify FMR errors are gone!


    Right. exit() is not magic, it is C, without (much) C++ awareness. It
    bypasses the destructor for ca, so that never tries to delete cb.

    After you fix your bug, never call exit() again. All C++ programs should
    find their way back to main()'s closing bracket.

    --
    Phlip
    http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
    Phlip, Sep 8, 2004
    #2
    1. Advertising

  3. John Black

    Unforgiven Guest

    "John Black" <> wrote in message
    news:...
    > Hi,
    > I wonder what is the difference between ending the main() with and
    > without exit(0)?
    >
    > Then the program exits with a core dump, in debugger I can see that
    > the core dump comes from "}" after "return 0;" in main() and "delete cb"
    > in ClassA::toExit().


    First of all, the dump is obviously because cb was never allocated but still
    deleted. If you're going to use NULL to check whether it's allocated or not,
    you should make sure it's also actually allocated.

    > Then I replace "return 0" with "exit(0)" in main(), everything is
    > fine: there is no core dump and purify FMR errors are gone!


    Indeed. This is because exit() is a function that never returns. As such,
    main() never reaches the end, and thus doesn't unwind its stack. As such,
    the ClassA destructor is not called, and the offending code is never
    reached.

    --
    Unforgiven
    Unforgiven, Sep 8, 2004
    #3
  4. John Black

    Howard Guest

    "John Black" <> wrote in message
    news:...
    > Hi,
    > I wonder what is the difference between ending the main() with and
    > without exit(0)?
    >
    > My code is like this flow,
    >
    > class ClassA{
    > ClassB* cb;
    >
    > int toExit();
    >
    > public:
    > ~ClassA();
    > ... constructors and all other API...
    >
    > }
    >
    > ClassA::~ClassA(){
    > this->toExit();
    > }
    >
    > ClassA::toExit(){
    > if (cb != NULL){


    You don't need to check for NULL here. Calling delete on a pointer whose
    value is NULL has no effect (good OR bad).

    BUT!... you need to either set cb to NULL in your constructor, or make sure
    it is assigned a valid value (using new) before this function is ever
    called.

    But why do you have a "toExit" function at all? Why not just delete the
    object inside your destructor? (If you're going to be creating and deleting
    the object more than once, you might want to rename it to something more
    meaningful, such as "DeleteB".)

    > delete cb;
    > cb = NULL;
    > }
    > }
    >
    > int main(int argc, char** argv){
    > ClassA ca;
    >
    > ... some operation ...
    >
    > return 0;
    > }
    >
    > Then the program exits with a core dump, in debugger I can see that
    > the core dump comes from "}" after "return 0;" in main() and "delete cb"
    > in ClassA::toExit().
    >
    > In purify it says some FMR, Free Memory Read errors.
    >
    > Then I replace "return 0" with "exit(0)" in main(), everything is
    > fine: there is no core dump and purify FMR errors are gone!


    Don't cal exit. It's not solving your problem, just hiding it!

    >
    > What's the trick here?
    >
    > Thanks.


    -Howard
    Howard, Sep 8, 2004
    #4
  5. John Black

    Alex Vinokur Guest

    Alex Vinokur, Sep 9, 2004
    #5
    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. QQ
    Replies:
    5
    Views:
    506
    Jonathan Adams
    May 10, 2005
  4. jacob navia
    Replies:
    3
    Views:
    543
    Nick Keighley
    Feb 24, 2010
  5. Keith Thompson
    Replies:
    10
    Views:
    675
    Tim Rentsch
    Mar 3, 2010
Loading...

Share This Page