3 ms·

You could just use C (or any other non-GC language) and opt out of freeing your memory. That it is done sometimes (not always intentionally, of course). The DM

You could just use C (or any other non-GC language) and opt out of freeing your memory. That it is done sometimes (not always intentionally, of course). The DMD Compiler for example: "DMD does memory allocation in a bit of a sneaky way. Since compilers are short-lived programs, and speed is of the essence, DMD just mallocs away, and never frees. This eliminates the scaffolding and complexity of figuring out who owns the memory and when it should be released. (It has the downside of consuming all the resources of your machine if the module being compiled is big enough.)" http://www.drdobbs.com/cpp/increasing-compiler-speed-by-over-75/240158941 http://www.drdobbs.com/cpp/increasing-compiler-speed-by-over...

joe_the_user 10y ago
The Qt C++ also allocates but never free a certain amount of memory. A lot of programs and libraries take the view that if you're going to allocate memory and keep using till the end, why bother freeing it? The downside to this is it makes it difficult to use tools like Valgrind that trace memory allocation in one's own program.
- 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 ago
    I'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).

joe_the_user 10y ago

The Qt C++ also allocates but never free a certain amount of memory. A lot of programs and libraries take the view that if you're going to allocate memory and keep using till the end, why bother freeing it? The downside to this is it makes it difficult to use tools like Valgrind that trace memory allocation in one's own program.

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 ago
  I'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).