CODEWITHSUNDEEP
c#c++garbage-collectiondispose
MasterMastic
MasterMastic

Reputation: 21286

Cleanup before termination?

This question has been bugging me for a while: I've read in MSDN's DirectX article the following:

The destructor (of the application) should release any (Direct2D) interfaces stored...

DemoApp::~DemoApp()
{
    SafeRelease(&m_pDirect2dFactory);
    SafeRelease(&m_pRenderTarget);
    SafeRelease(&m_pLightSlateGrayBrush);
    SafeRelease(&m_pCornflowerBlueBrush);
}

Now, if all of the application's data is getting released/deallocated at the termination (source) why would I go through the trouble to make a function in-order-to/and release them individually? it makes no sense!

I keep seeing this more and more over the time, and it's obviously really bugging me. The MSDN article above is the first time I've encountered this, so it made sense to mention it of all other cases.

Well, since so far I didn't actually ask my questions, here they are:

Thank you!

Upvotes: 5

Views: 487

Answers (2)

John Dibling
John Dibling

Reputation: 101456

Now, if all of the application's data is getting released/deallocated at the termination (source) why would I go through the trouble to make a function in-order-to/and release them individually?

A number of reasons. One immediate reason is because not all resources are memory. Only memory gets reclaimed at process termination. If some of your resources are things like shared mutexes or file handles, not releasing those resources could mess up other programs or subsequent runs of your program.

I think there's a more important, more fundamental reason though. Not cleaning up after yourself is just lazy, sloppy programming. If you are lazy and sloppy in cleanup at termination, are you lazy and sloppy at other times? If your tendancy is to be lazy and sloppy and only override that tendancy in specific areas where you're cognizant of potential problems, then your tendancy is to be lazy and sloppy. What if there are potential problems you're not cognizant of? How can you rely on your overall philosophy of lazy, sloppy programming to write correct, robust programs?

Don't be that guy. Clean up after yourself.

Upvotes: 3

Servy
Servy

Reputation: 203835

You don't need to worry about managed content when your application is terminating. When the entire process's memory is torn down all of that goes with it.

What matters is unmanaged resources.

If you have a lock on a file and the managed wrapper for the file handler is taken down when the application closes without you ever releasing the lock, you've now thrown away the only key that would allow access to the file.

If you have an internal buffer (say for logging errors) you may want to flush it before the application terminates. Not doing so would potentially mean the fatal error that caused the application to end isn't logged. That could be...bad.

If you have network connections open you'll want to close them. If you don't then the OS likely won't do it for you (at least not for a while; eventually it might notice the inactivity) and that's rather rude to whoever's on the other end. They may be continuing to listen for a response, or continuing to send you information, not knowing that you're not there anymore.

Upvotes: 3

Related Questions