The issue relates to allocation, right? So the issue isn’t going to be with that code, that just calls append, the issue is with your allocator
#question about lists and appending local scope data (General protection Exception)
lone surge
My guess, because is a common mistake, is that arena.allocator() creates an allocator on the stack (ie inside of init) and then when init finishes running, that allocator is destroyed, leaving the array without a valid allocator. (I’m on my phone so it’s possible I’m wrong here.)
Most of the time it’s recommend to use ArrayListUnmanaged and pass it the allocator stored in your struct (.alloc) instead of using ArrayList for this reason.
dusty umbra
More precisely, arena.allocator() returns a value that contains (and thus holds on to) &arena -- which is a local variable, and so whos space is reused over time.
dusty umbra
Well - it depends on what you're doing and why. There's a lot of options.
One option is to just not do so; to have every function that would use the allocator do self.arena.allocator() wherever it needs to, and remove the alloc field.
Another is to have pub fn init(self: *Arena, ...) and initialize in-place instead.
self.arena = .init(alloc.*)
(You don't actually need alloc: *std.mem.Allocator; alloc: std.mem.Allocator is fine
because Allocator already points to the state
)
dusty umbra
o7
finite island
Allocator is a fat pointer, *Allocator is basically pointing to a pointer
finite island
One option is to just not do so; to have every function that would use the alloc...
also is this syntax real? .init(...) or just pseudo ish
dusty umbra
also is this syntax real? `.init(...)` or just pseudo ish
It's decl literals.
Modern feature