3 ms·
There are two significant downsides to freeing blocks of memory that are in use when program exits: 1) it's completely wasted effort to track who should free so
by dfox 10y ago
There are two significant downsides to freeing blocks of memory that are in use when program exits:
1) it's completely wasted effort to track who should free some global structure that gets allocated and then exists until program ends (global singletons, various caches...)
2) freeing all objects when program exits puts completely unnecessary pressure on OS's VM subsystem (it's not so long ago that closing long-running firefox or openoffice caused linux desktop to just freeze and swap for few seconds)
Maybe I'm in minority but in C I tend to flag unnecessary free()'s before program exit in code reviews (There is not much that you can do about that in "safe" languages like C++).
- joe_the_user 10y agoI'm not saying this somewhat common method is necessarily bad. I'd just mention it makes tracking memory allocation harder for an end-user of an application framework that does. In those instances, it might be nice to, say, disable this approach with compiler flag or something. Edit: it also depends on how concerned you are with memory leaks. Making sure every single allocation has a delete attached is a simple rule. The rule of "every allocation has a delete, except the allocations we're sure will last for the life of the program", making sure that rule is followed seems a little harder and presents a "mental overhead". This kind of thing probably depends on how prone to memory leaks your program is (I've seen big, messy, memory leak prone programs where "oh this one isn't deleted 'cause of optimization" would make the leak-detective's job just that much harder).