   Trivial deallocations?
  I was wondering about a rather common situation:Application is about to be terminated and it is time for the cleanup.Naturally there are critical parts that must be released, or they will linger about indefinately  ( Mainly COM - objects on windows platform ).However, what is the direct benefit in actually releasing up all the heap-memory that the OS will deallocate automatically when program terminates. Since a quick shutdown is something to be appreciated, deallocating stuff that gets trivially released in any case seems a bit pointless.Can anyone come up with a better reason than "good practise"?   
  It helps leak detection. Other than that I usually add a #ifdef around the final deallocation in release builds There is no point in releasing heap memory when the program is about to die.   ;  Thanks for the reply.The cleanup-process seems like a valuable tool afterall. :)   ;  By the way, calling destructors can be about more than just "deallocating memory". The OS might reclaim the memory but still have trouble with e.g. file handles or locked files.   ;Quote:Original post by ZahlmanThe OS might reclaim the memory but still have trouble with e.g. file handles or locked files.I cannot speak for Windows, but on Linux (and most likely on other Unices) it's completely unnecessary.   ;Quote:Original post by uQuote:Original post by ZahlmanThe OS might reclaim the memory but still have trouble with e.g. file handles or locked files.I cannot speak for Windows, but on Linux (and most likely on other Unices) it's completely unnecessary.Careful. There are in fact some resources on UNIX-like systems that persist after application termination if you don't release them. One example is SysV shared memory.   ;Quote:Original post by the_eddCareful. There are in fact some resources on UNIX-like systems that persist after application termination if you don't release them. One example is SysV shared memory.True. I completely forgot about that, apologies. (The examples given were file handles and locked files, which do not need any releasing.)   ;  Windows is the same way. Anything "owned" by the application will be deallocated automatically. (memory, file handles, critical sections, that sort of thing)   ;Quote:Original post by the_eddCareful. There are in fact some resources on UNIX-like systems that persist after application termination if you don't release them. One example is SysV shared memory.Resources owned by process are cleaned up.Anything not owned by process (shared memory, files, remote resources, database contents) are not cleaned up. GPU memory, excluding potential driver bugs, does not fall under this.The obscure corner case is security related, such as cleaning up the memory that might have been paged and could potentially contain sensitive data. In this case either disabling the page file, purging it on each restart, or using non-pagable memory can be used, albeit this is a rare scenario and implemented mostly if required by some regulation.This is a distinction often forgotten, especially in case of a crash.This thread has a somewhat broader view on the matter, as well as discussion on possible benefits of exiting fast without cleanup, along with gotchas associated with such approach.A well written application should be aware of all resources allocated, and manage them appropriately.   ;  I tend to view this from the perspective of robustness.If my code is well-written, I can safely ignore the distinction between a "I'm closing permanently" program state and a "I want to return to my initial state" situation. For example, in a game, quitting out to the main menu and then restarting a game shouldn't be appreciably any different from just loading the game to begin with. (I of course ignore situations like caching data for faster load times, etc.; use your common sense here.)IMHO I shouldn't have any need to recognize a final-close situation, because if my resource management is written correctly, any non-final cleanup should behave precisely as a final cleanup does.   