Yeah, so it seems like my expectation was correct. The problem I have with that design decision (which matches that of Odin as well) is that it forces code written for an abstract allocator - for which the implementation can change - to use the *maximally generic allocator API*. With an arena, the burden of freeing individual allocations…
Yeah, so it seems like my expectation was correct. The problem I have with that design decision (which matches that of Odin as well) is that it forces code written for an abstract allocator - for which the implementation can change - to use the *maximally generic allocator API*. With an arena, the burden of freeing individual allocations all but disappears (except when doing more complex allocators on top of an arena, e.g. a pool allocator) - so code written for an arena is much simpler than code written for a generic allocator (even if that generic allocator no-ops on all of the frees, and indeed is implemented with an arena). The generic interface remains a pessimization for the allocator usage code.
The "granular bookkeeping" you mention (for more complex data structures) is what I describe as "a more complex allocator that composes with an arena", e.g. the free-list + arena introduced in the post. So it's definitely possible, it's just that it requires *composition with an arena*. The approach of e.g. Zig and Odin is to *abstract over the allocator*, but I disagree with their approach - instead, use the simplest allocator as a building block, and add more building blocks as necessary.
Regarding the government line, glad you enjoyed it. I have to sneak in my ancap somewhere. :)
Yeah, so it seems like my expectation was correct. The problem I have with that design decision (which matches that of Odin as well) is that it forces code written for an abstract allocator - for which the implementation can change - to use the *maximally generic allocator API*. With an arena, the burden of freeing individual allocations all but disappears (except when doing more complex allocators on top of an arena, e.g. a pool allocator) - so code written for an arena is much simpler than code written for a generic allocator (even if that generic allocator no-ops on all of the frees, and indeed is implemented with an arena). The generic interface remains a pessimization for the allocator usage code.
The "granular bookkeeping" you mention (for more complex data structures) is what I describe as "a more complex allocator that composes with an arena", e.g. the free-list + arena introduced in the post. So it's definitely possible, it's just that it requires *composition with an arena*. The approach of e.g. Zig and Odin is to *abstract over the allocator*, but I disagree with their approach - instead, use the simplest allocator as a building block, and add more building blocks as necessary.
Regarding the government line, glad you enjoyed it. I have to sneak in my ancap somewhere. :)