There are a couple of approaches that might legitimately be simpler than using a general-purpose allocator: in a single-pass batch process, just throw things on

There are a couple of approaches that might legitimately be simpler than using a general-purpose allocator: in a single-pass batch process, just throw things on the floor and let the OS sort it out on exit[1] (I think the D compiler does this); in a multiple-pass batch process, make each pass litter its own room (arena, obstack, etc.) then demolish said room when done (GCC does this or at least did in the past). On the other hand, these may require rearranging the logic somewhat to fit them, so the question of how much rearrangement to tolerate still remains. And, well[4], /* * We divy out chunks of memory rather than call malloc each time so * we don't have to worry about leaking memory. It's probably * not a big deal if all this memory was wasted but if this ever * goes into a library that would probably not be a good idea. * * XXX - this *is* in a library.... */ [1] I am rather dismayed by how Raymond Chen advocates for this for memory[2] but insists it could not possibly be a good idea for Windows GDI handles, no, you stupid sloppy programmer[3]. Maybe because he was involved in GDI from the other side? (Of course, for file descriptors on Unix it’s still the standard practice.) [2] http://bytepointer.com/resources/old_new_thing/20120105_006_when_dll_process_detach_tells_you_that_the_process_is_exiting_your_best_bet_is_j.htm http://bytepointer.com/resources/old_new_thing/20120105_006_... [3] http://bytepointer.com/resources/old_new_thing/20051014_305_thread_affinity_of_user_interface_objects_part_5_object_clean_up.htm http://bytepointer.com/resources/old_new_thing/20051014_305_... [4] https://github.com/the-tcpdump-group/libpcap/blob/4c1e516dd2971810918babcd871e428db53383e4/gencode.c#L221 https://github.com/the-tcpdump-group/libpcap/blob/4c1e516dd2...