Sign in to follow this  
noodlyappendage

What happens if I don't deallocate dynamic memory on application exit?

Recommended Posts

I was just wondering what, if any, negative effect the following scenario would have. I create an object instance using the new operator. This object then exists for the life of the entire process. Then, when exiting the application, I do not call a corresponding delete to deallocate. I understand the problem with memory leaks in terms of memory usage of the process at run time, but if the application is exiting, wouldn't the operating system free up any memory it had used anyway?

Share this post


Link to post
Share on other sites

If you need security of anything in RAM, you must use mlock or VirtualLock or the like.

 

I had never heard of these before, and decided to google it to learn more. I stumbled upon this link, http://blogs.msdn.com/b/oldnewthing/archive/2007/11/06/5924058.aspx, which is saying that when using VirtualLock, it is still possible for memory to be paged out by the operating system. It is a few years old though, so is this information still accurate? 

 

Edit: Actually, I just noticed at the bottom, the author includes a follow up which says his interpretation was incorrect, and VirtualLock is sufficient to secure memory. However I still found it to be an interesting read anyway.

Edited by noodlyappendage

Share this post


Link to post
Share on other sites

Also, if your destructor has observable side effects, then not calling delete may result in undefined behaviour (I'm not comfortable enough with C++ to tell whether it is for sure, maybe someone else can answer that, but you should probably check).

Sure, if a destructor does something like, say, records the last known window positions and sizes, and you fail to call the destructor (via delete or whatever), then those settings won't get saved. Or if you were supposed to write something to the registry or send a "logout" packet to a server, or whatever.

 

Generally, it's your responsibility to clean up after yourself. Now, knowing that things will be cleaned up anyway (but at the expense of not running the destructors), you, as a developer, might make a conscious decision to, in that circumstance, let the OS clean it up. But by default, you should clean it up unless you have a reason not to.

 

If your problem is you just don't want to bother - good news: You probably shouldn't be calling 'delete' on anything anyway, because you probably shouldn't be calling 'new' either. In C++, you'd put most your objects as local variables and member variables, and the rest of your objects in containers or smart pointers - again, less you have a reason not to.

 

In my own code, I'd (very roughly) estimate less than 10% of my variables are dynamically allocated, and of those 10%, only 1% uses new and delete directly.

Share this post


Link to post
Share on other sites
dmatter    4826

A mature OS will deallocate memory on exit of the application, which answers your question. But knowing that should just be a curious tidbit because whether or not memory is freed by the OS is not really that relevant or useful...

 

Cleaning up after yourself is about more than just deallocating memory, it's also about running destructors which themselves may have side-effects (freeing other kinds of resources, flushing buffers, saving state, etc).

 

It's also not something you should really need to worry about in modern C++ code since all heap allocated memory should be being auto-deallocated by a stack-bound RAII container. The delete keyword is effectively deprecated under normal use and relegated for use only for implementing RAII containers or for extenuated circumstances such as interfacing with legacy code/frameworks.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this