3 ms·
My thought when reading this, as someone who has never used zig, wouldn't it be easier with a global (thread local) variable? If you don't care you don't touch
by im3w1l 1y ago
My thought when reading this, as someone who has never used zig, wouldn't it be easier with a global (thread local) variable? If you don't care you don't touch it. If you you do care you change it and restore it when you are done with whatever you were doing.
- dundarious 1y agoThat would get you almost none of the benefits of arenas and other types of allocators. Recommend https://www.rfleury.com/p/untangling-lifetimes-the-arena-allocator https://www.rfleury.com/p/untangling-lifetimes-the-arena-all...
- im3w1l 1y agoI know what arenas are but I don't see how passing something explictly vs implicitly matters except for which style people prefer?
- dundarious 1y agoFor one, you don't want exactly one arena or allocator for all tasks.
- im3w1l 1y agoWell you couldn't you just use a different one in that case? The variable would just be like a suggestion.
- dundarious 1y agoMost programmers don't prefer thread local mutable state over a single pointer argument. Especially for general purpose code (i.e., not specific to a single purpose/project). With the mutable state version, you have to clearly define which state you're using and when (which named allocator/arena variable), and if you're mutating it in place and then restoring it, there can be some pretty obvious issues. Given this thread is completely off the rails from anything specific to allocators or arenas, and even Zig, I will now exit.
- chrisco255 1y agoYou can use regular buffers for many things, but a lot of core Zig std functions require an allocator (satisfying std.mem.Allocator interface) as an argument. This means the developer retains control of how memory is managed. It's also advantageous for testing, as you can pass in specialized allocator for detecting memory leaks during testing but use the more efficient allocator for release mode. You can wrap regular buffer into a FixedBufferAllocator which just uses stack values. ArenaAllocator is just a container that wraps an underlying allocator but it will free everything when you call defer arena.deinit(), which is useful for short-lived things like http requests.
- defen 1y agoDoing that seems like it's just manually replicating a call stack (with potential for error); I don't see what the benefit is. Making functions independent of global state - and allocation is a huge source of implicit dependency on global state - is generally considered good programming practice.