I just ran into something I never realized was a problem: I know that list1 would call new 100 times for each of the ints, and if called, its ~destructor would clean that up. However, since it's on the stack, and I call exit(0) rather than return 0, is its ~destructor even called? According to a simple test I did with my own class, it's not! According to exit() description, it's supposed to "Terminate the process normally, performing the regular cleanup for terminating processes." That doesn't seem to be a normal clean up to me, as it creates memory leaks. Is there any way of using exit() to exit without such side-effects, or is my only way to be sure everything is cleaned up is to call return 0; from main()? Thanks in advance.

exit() will perform normal C cleanup, calling atexit() handlers, etc. However, it generally won't perform stack unwind cleanup for C++ objects on the stack.

Right.

So my question then is: Is there any safe way to use exit() to exit from within the middle of an application without potentially leaving memory allocated on the stack behind (i.e. creating a memory leak)?

Dynamically allocated memory is not a problem, as I can clean it up myself just before exiting.

If not, what's a good method to self-terminate a program? Is returning from main() the only safe way?

Basically, returning from main() is the only way that C++ will guarantee that everything will shut down properly. Specific C++ implementations may have other mechanisms. For example, most C++ implementations will clean up properly if you have an unhandled exception, but it's not guaranteed to work.

Okay, I'll adapt my code to have Terminate() set some condition variable like 'running' to false, instead of calling exit() explicitly. That will make the program fall out of the main loop, and eventually get to the bottom of main().

That's probably not the best way though...

Thanks for the help.

I thought a memory leak was when you exit without deallocating all the memory that you've allocated (usually memory dynamically allocated on the heap, but I don't see why memory allocated on the stack wouldn't count).

Now you've made me unsure, lol. Does an OS have some magical way to restore (i.e. make avaliable for future use; mark as 'free memory') all the memory allocated to a program when it exists, even if that program itself doesn't clean up after itself? I think not... right? But then again, if a program always allocates memory for itself within its own memory space, it *might* be possible...

So what's the scoop on this?

Edit: Wow, apparently that might be true, about the OS forcebly cleaning up after a program terminates. According to wikipedia, anyway:

"In modern operating systems, normal memory used by an application is released when the application terminates. This means that a memory leak in a program that only runs for a short time is rarely serious."

This is starting to make sense along with what I've learned in my OS class. I can't believe I never realized this was the case, until now. Well, I could use more assurance from other people to be completely sure...

Does that make it safe to exit() while leaving allocated memory behind?

Wow, I can't believe how one's world, once thought to be solid and stable for so long, can be turned upside down by a simple finding like this lol. It goes against everything I've learned and thought about so far...

It's a memory leak imo. The application doesn't deconstruct properly. Beyond the obvious issues with stuff like memory, what about other handles the process has open? There's many things you can leak and different operating systems will behave differently when trying to clean up the process after exit. Some embedded systems might not clean it at all, older versions of Windows didn't either. Making it exit properly here is trivial and you're aware of the issue so there's no reason except laziness to not fix it imo.

Ok, so not all hope is lost then - at least it's still a good programming practice not to leave memory leaks behind. :) Maybe I'm not that useless after all then. :D

Thanks.

Still, I can't believe I never realized that Windows XP does clean up after programs that do create memory leaks while running. Now that I think about it, it seems so obvious (I can think of many examples in the past that confirm this behaviour). This probably wasn't the case in Win 98, was it?