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.
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.
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.
Seriously
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.