and then append to arr, then arr will have capacity 8.
But if you did
arr := make([dynamic]int, context.temp_allocator)
then arr would have capacity 16.
Behavior now
Now both arr: [dynamic]int and arr := make([dynamic]int, context.temp_allocator) will result in arr having cap 0.
The only reason to use make without an explicit len or cap now is because you want to set it up for a non-default allocator. After the first call to append it will now in both cases have capacity 8.
There was a hard-coded 8 in append and then there was a default reserve capacity constant set to 16. The constant has been changed to 8 and is used in append now, while make uses capacity 0.
I have updated the documentation in the strings builder to reflect this. There were also some inaccuracies in there that weren't true even before these changes (such as len being max(16, len) when you specify len for a builder).
Positive side effects of this
Say you have a proc like this, that fetches all trees that are near a video game player within a certain distance:
find_all_nearby_trees :: proc(max_distance: f32, allocator := context.allocator) -> []^Tree {
trees := make([dynamic]^Tree, allocator)
for &t in world.trees {
if linalg.length(t.pos - player.pos) < max_distance {
append(&trees, &t)
}
}
return trees[:]
}
Then if there are no trees nearby, then with the new code no allocation at all will happen. With the old code there would always be an allocation of capacity 16.
Behavior before
Before these changes, if you did:
and then append to arr, then
arr
will have capacity8
.But if you did
then
arr
would have capacity16
.Behavior now
Now both
arr: [dynamic]int
andarr := make([dynamic]int, context.temp_allocator)
will result in arr having cap 0.The only reason to use
make
without an explicit len or cap now is because you want to set it up for a non-default allocator. After the first call toappend
it will now in both cases have capacity 8.There was a hard-coded 8 in
append
and then there was a default reserve capacity constant set to 16. The constant has been changed to 8 and is used in append now, whilemake
uses capacity 0.I have updated the documentation in the strings builder to reflect this. There were also some inaccuracies in there that weren't true even before these changes (such as len being
max(16, len)
when you specify len for a builder).Positive side effects of this
Say you have a proc like this, that fetches all trees that are near a video game player within a certain distance:
Then if there are no trees nearby, then with the new code no allocation at all will happen. With the old code there would always be an allocation of capacity 16.
Tests done
I tested this using this program
Output:
I also tested this with my current game prototype, it all worked fine.