Hacker News new | ask | show | jobs
by nusaru 14 days ago
Why not use an arena allocator?
1 comments

Tbh I don't know enough Zig to answer that. Can you give an example? E.g. some non-performance-sensitive function that returns a string? In Rust and C++ you can treat the string exactly the same as you would an integer and it's super easy.

In C you have pain. Does the caller allocate a buffer? How does it know how big to make it? Do you have to have separate calls to calculate the required length? Etc. Can Zig work like Rust/C++ and not like C? My impression is that it can't.

An arena allocator lets you treat a series of allocations as a single block. In cases where you find yourself needing to micromanage a bunch of small memory allocations you can simply ignore freeing them individually and free the whole arena when you are done.
Yeah sorry I know what an arena allocator is. I meant how can you write code that deals with strings (joining, formatting, passing around etc.) but isn't sensitive to performance (so `std::string`-like performance is fine) in Zig without having to deal with tedious low level allocator details. If I have to pass an allocator around everywhere that's a pain in the bum.

Apparently Zig doesn't have a global allocator so it seems like you can't. (And it seems like the allocation details aren't encoded in the type anyway so it will be a disaster if you start mixing up global and non-global allocator types anyway.)

Passing an allocator around is a design choice of Zig, so yeah, it is not supposed to be avoided