Skip to main content
23 events
when toggle format what by license comment
Jan 24, 2021 at 19:02 review Suggested edits
Jan 24, 2021 at 19:09
Jan 3, 2016 at 22:07 history edited Doc Brown CC BY-SA 3.0
deleted 7 characters in body
Dec 29, 2015 at 19:40 comment added WGroleau Another good habit is that the subprogram (method, function, etc.) that does the allocation should do the deallocation.
Dec 28, 2015 at 21:17 history edited Doc Brown CC BY-SA 3.0
added 22 characters in body
Dec 28, 2015 at 21:14 comment added Felix Dombek Good answer, it might be worthwhile to add that having code to free all memory makes it much easier to refactor the code later if additional things need to happen before/during freeing -- e.g. running destructors or a new cleanup function. It is clear where to add those if the free instruction is already in place, and can be hard otherwise (even if the actual lifetime of the memory does not need to be controlled).
Dec 28, 2015 at 19:12 comment added Deduplicator @KyleStrand: That presumes the stack is big enough for it, the main-thread will persist until the end, and the language allows stack-allocating it safely (which probably means it has to be of fixed size). Likely using static memory is more sensible, if possible.
Dec 28, 2015 at 17:25 comment added Kyle Strand Additionally, if the memory really needs to exist for the entire lifetime of the program, it may be a sensible alternative to create a structure on the stack, e.g. in main.
Dec 28, 2015 at 8:47 comment added Akshay Arora +1 for second bullet point. This may sound simple, but is very important when building modular content.
Dec 27, 2015 at 23:49 comment added Thomas @GrandOpener In this case you might prefer to use some kind of region-based allocator for this tree, so that you can allocate it in the normal way and just deallocate the entire region at once when the time comes, instead of traversing it and freeing it bit by bit. That's still "proper".
S Dec 27, 2015 at 20:17 history suggested Deduplicator CC BY-SA 3.0
minor touchups
Dec 27, 2015 at 19:54 comment added Peter Cordes It's safe on every modern "normal" (non-embedded with memory protection) OS, and would be a serious bug if it wasn't. If an unprivileged process can permanently lose memory that the OS won't reclaim, then running it many times can run the system out of memory. The long-term health of the OS can't depend on lack of bugs in unprivileged programs. (of course, this is ignoring things like Unix shared-memory segments, which are only backed by swap space at best.)
Dec 27, 2015 at 19:45 review Suggested edits
S Dec 27, 2015 at 20:17
Dec 27, 2015 at 19:13 vote accept CaptainObvious
Dec 27, 2015 at 19:10 history edited Doc Brown CC BY-SA 3.0
added 252 characters in body
Dec 27, 2015 at 18:35 history edited Doc Brown CC BY-SA 3.0
added 140 characters in body
Dec 27, 2015 at 17:34 vote accept CaptainObvious
Dec 27, 2015 at 18:14
Dec 27, 2015 at 16:45 comment added GrandOpener Generally I agree strongly with this advice. Keeping good habits with memory is very important. However, I think there are exceptions. For example, if what you've allocated is some crazy graph that's going to take several seconds to traverse and free "properly," then you'd be improving the user experience by just ending the program and letting the OS nuke it.
Dec 27, 2015 at 10:50 comment added Lawrence Good point about developing good programming habits.
Dec 27, 2015 at 9:09 history edited Doc Brown CC BY-SA 3.0
added 249 characters in body
Dec 27, 2015 at 9:03 history edited Doc Brown CC BY-SA 3.0
added 249 characters in body
Dec 27, 2015 at 8:47 history edited Doc Brown CC BY-SA 3.0
added 249 characters in body
Dec 27, 2015 at 8:40 history edited Doc Brown CC BY-SA 3.0
added 219 characters in body
Dec 27, 2015 at 8:36 history answered Doc Brown CC BY-SA 3.0