Buffers and allocators #15
Conversation
| // The NullAllocator is meant to be used as a fallback | ||
| // for allocator composition. | ||
|
|
||
| // For example, a StackAllocator, if it runs out of memory, | ||
| // can dispatch to another allocator to fulfill the request. | ||
| // If we want that to signal an error, we can give it the | ||
| // NullAllocator as a fallback and that will signal an | ||
| // "OutOfMemory" error, enforcing that we don't ask for | ||
| // more memory than is on the stack. |
There was a problem hiding this comment.
This is actually pretty genius!
There was a problem hiding this comment.
It's also possible to use this for something like an allocator that can be "turned off" by mutating itself and replacing its composed allocator with this allocator.
There was a problem hiding this comment.
Huh, now that's an interesting idea. Since we can access the member variables directly in Zig, I think this is something that we can already express?
| backing_allocator: std.mem.Allocator, | ||
|
|
||
| // TODO: Create a dummy mutex that can be swapped via policy | ||
| mutex: std.Thread.Mutex = std.Thread.Mutex{ }, | ||
|
|
||
| pub fn init(fallback: std.mem.Allocator) Self { | ||
| return Self { | ||
| .backing_allocator = fallback, | ||
| .buffer = OrderedCache.init(std.heap.page_allocator) | ||
| }; | ||
| } | ||
|
|
| pub fn itemCount(self: *const Self) usize { | ||
| return self.idxs.len; | ||
| } |
There was a problem hiding this comment.
What do you think about this as a convention?
len-- Collection is linear (array/list/etc) and size is known O(1)size-- Collection size is statically known O(1)count()-- Collection size will be dynamically computed at O(n)
Whether len or size are struct members or functions depends on the details
There was a problem hiding this comment.
I like that idea! I honestly ran out of synonyms at that point.
So the reason I did itemCount in this case is because I did the same thing in the RegularBuffer (but that one has a good reason to exist... it's calculated on the fly so a division operation has to occur).
Okay, so in that case... the RegularBuffer should have a count() function, and this one should have a len() function?
There was a problem hiding this comment.
I think so, and probably we should start a CONVENTIONS.md or something?
There was a problem hiding this comment.
So here's my proposal:
len - refers to retrieving a data member that continually keeps track of the number of elements
size - refers to retrieving a non-mutable (or statically known) number of elements
count - refers to anything that must calculate the number of elements regardless of complexity (it's literally counting)
There was a problem hiding this comment.
Oops I never responded... I think that's great
Added null_allocator, regular_buffer, irregular_buffer, and updated existing allocators.