return vs exit

J

John Black

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.
 
P

Phlip

John said:
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.
 
U

Unforgiven

John Black said:
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.
 
H

Howard

John Black said:
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
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,055
Latest member
SlimSparkKetoACVReview

Latest Threads

Top