Odin claims to be pragmatic (what language doesn't lol) but "All procedures that returned allocated memory will require an explicit allocator to be passed". Charitably, is this aimed at c/zig heads?
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.
> Dynamic scope would likely be heavier than what Odin has, since it'd require the language itself to keep track of this
Not necessarily, you can imagine that malloc() itself has an API that says "temporarily switch calls on this thread to a different allocator" and then you undo it later.
> 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.
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.
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)
> 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.
The usual thing for languages is to provide a global allocator. That's what C's malloc is doing for example. We're not asked to specify the allocator, it's provided by the language runtime so it's implied everywhere.
In standalone C, or Rust's no_std, there is no allocator provided, but most people aren't writing bare metal software.
If you need multiple allocators, and you aren't already using lisp, who cares? Just use lisp. Anyone who can use allocators against the C abi can clearly see the benefits of using a language that can cater to the developer. Zig can never do this, yea even with its shallow macros. Zig will always be a shitty B knockoff rather than something artisans actually want to use
You call the use of memory something other than "allocation". Ez.
I thought that passing down allocators was core to the language. I was mistaken. This is actually quite nice for writing allocation code when you'd like to opt into it.
