Comment by acheong08
2 months ago
Allocation in Zig takes some getting used to but it's actually really nice. It took me a few weeks but I honestly believe you should give it another chance and more time
2 months ago
Allocation in Zig takes some getting used to but it's actually really nice. It took me a few weeks but I honestly believe you should give it another chance and more time
I personally find it much more ergonomic to have the allocator attached to the type (as in Ada). Aside from the obvious benefit of not needing to explicitly pass around your allocator everywhere, it also comes with a few other benefits:
- It becomes impossible to call the wrong deallocation procedure.
- Deallocation can happen when the type (or allocator) goes out of scope, preventing dangling pointers as you can't have a pointer type in scope when the original type is out of scope.
This probably goes against Zig's design goal of making everything explicit, but I think that they take that too far in many ways.
There is no reason you can't attach an Allocator to the type (or struct, in Zig).
A fairly common pattern in the Zig stdlib and my own code is to pass the allocator to the `init` function of a struct.
If what you mean is that allocation should be internal to the type, I don't agree with that. I much prefer having explicit control over allocation and deallocation.
The stdlib GPA for example is pretty slow, so I often prefer to use an alternative allocator such as an arena backed by a page allocator. For a CLI program that runs and then exits, this is perfect.
Same can be said about Borrow Checker.