3 ms·
What I wrote about is not GC. The other comments about reference counting also unfortunately completely miss the point I made. The code stays simple as nothing
by eska 2y ago
What I wrote about is not GC. The other comments about reference counting also unfortunately completely miss the point I made.
The code stays simple as nothing is happening in the background like a GC or macro abuse. For example you clearly see where allocations can happen now in join_path(temp_arena, basedir, filepath). At the same time I‘m not calling free everywhere and can avoid a lot of the „goto cleanup“ dance or the gcc-specific extension.
Frankly I feel like understanding this approach to memory management is the best way to snuff out C experts from juniors/wannabes.
- indigoabstract 2y ago> What I wrote about is not GC. The other comments about reference counting also unfortunately completely miss the point I made. I know. I mentioned the GC because of another comment and because reference counting and GCs are the two usual general ways (that I know of) for automating memory management. That's what I had in mind. Unless I'm misunderstanding, arena allocators are most useful for categories of objects with similar lifetimes and are not in the fully automated category. Because if I have multiple arena allocators, I still have to manually assign an allocator when creating an object and also deal with the lifetimes of the allocators themselves. Easier than allocating/deallocating individual objects in main memory with malloc, true, and probably more efficient, but still not fully automated, so in my mind they have different use cases. But it's possible that I haven't really understood them, so if I'm mistaken about their use, please don't leave me in the dark. If that makes me look like a junior wannabe, I think I can take it. Even the people who know their stuff had some point when they didn't..