I'm guessing it's aimed at game development since Vulkan has a similar pattern in every function call (although optional, the driver does it's own allocation if you pass null).
As another commenter wrote "how do you allocate memory without an allocator?"
Even `malloc` has overhead.
> Wouldn't dynamic scope be better?
Dynamic scope would likely be heavier than what Odin has, since it'd require the language itself to keep track of this - and to an extent Odin does do this already with `context.allocator`, it just provides an escape hatch when you need something allocated in a specific way.
Then again, Odin is not a high level scripting language like Python or JavaScript - even the most bloated abstractions in Odin will run like smooth butter compared to those languages. When comparing to C/Rust/Zig, yeah fair, we'll need to bring out the benchmarks.
> and to an extent Odin does do this already with `context.allocator`
It has a temporary allocator as well, which could track memory leaks. Not so much anymore though, IIRC.
> As another commenter wrote "how do you allocate memory without an allocator?
I would like to point out that this is basic knowledge. At first I was wondering if I have gone insane and it really is not the case anymore or something.
> As another commenter wrote "how do you allocate memory without an allocator?"
You call these things something other than an "allocating" and "allocators". Seriously, few people would consider adding a value to a hashmap an intentionally allocational activity, but it is. Same with adding an element to a vector, or any of the dependent actions on it.
Yep exactly, at it's simplest all an allocator is doing is keeping track of which memory areas are owned and their addresses. In a sense even the stack pointer is a kind of allocator (you can assign the memory pointed to by the stack pointer and then increment it for the next use)
For "adding an element to a vector" it's actually not necessarily what you meant here and in some contexts it makes sense to be explicit about whether to allocate.
Rust's Vec::push may grow the Vec, so it has amortized O(1) and might allocate.
However Vec::push_within_capacity never grows the Vec, it is unamortized O(1) and never allocates. If our value wouldn't fit we get the value back instead.
