It means that to do variable sized things like vectors and strings, C++ often ends up having to allocate their contents dynamically. Which results in data structures with lots of 64-bit pointers over multiple allocations.

Even Rust's "enum" feature, which can store different sized things all in the same space, does that at the cost of the smallest variant being just as big as the biggest.

Goose can do all of that not only inline (no pointers), but with variable size, meaning small items take less space. It's like a serialized data representation, but iterable. It makes for big space savings vs these languages.

▲

eslaught 6 hours ago | parent | next [-]

As far as I can tell, you're essentially creating a new stack for every dynamically-sized variable (because otherwise nothing would be able to grow by bump allocation without moving). But this means you're creating a separate virtual memory allocation for each of these objects, which (I presume?) then rounds the size up to the OS's minimum page size (4KiB or similar).

Doesn't that waste a lot of space? Or is there something I'm missing?

Also it would seem to force every allocation to go through the OS kernel to allocate unless there's some trick to avoid that.

▲

vanderZwan 5 hours ago | parent | next [-]

I think what you might be missing is that you can also do a sort of livenes analysis to determine how many dynamically-sized variables are "awake" at the same time at most. Then you only need to create as many stacks as that number, because you can reuse the stacks of "sleeping" variables (since the "awake" variables are guaranteed to be freed once their block goes out of scope, and threads don't share any memory so no data race worries regarding those stacks).

For example, suppose we have a function with a growable array that calls another function (without passing said array) that also uses a growable array as some temporary scratch space. Then the first function's array isn't being used when the second is sleeping, so the inner function's array could safely share the stack because it will all be freed with a single pointer restore once the second function exits.

Now, I actually don't know how the compiler works but as I understand it does things similar to my example to optimize the number of stacks needed (but let's wait for WvO to confirm or deny whether my understanding matches reality).

	▲	Xirdus 3 minutes ago \| parent [-]
		The obvious question is how does it work for linked lists, trees, and other non-stack-shaped data structures?

▲

Aardappel 5 hours ago | parent | prev [-]

Only top level growable arrays get their own "stack", if you create an array of arrays it only uses one stack.

How you deal with the inner stack growing depends, ideally they don't grow (construction only), or you can make them fixed size, or with a capacity, or in the worst case, as a pool. The language has facilities for all of these.

▲

amluto 4 hours ago | parent [-]

What’s the “pool” case? A function allocates a growable arena in normal heap or virtual memory?

	▲	Aardappel 4 hours ago \| parent [-]
		https://aardappel.github.io/goose/docs/reference.html#14-reu...

▲

koolba 6 hours ago | parent | prev | next [-]

These AI generated docs would make more sense if you instruct it to not include numbers unless they form a complete example.

▲

randfur 2 hours ago | parent | prev [-]

I wish it was more clear about the memory layout of nested variable sized data structures. As far as I can work out the max capacity is decided at construction time which makes the whole thing a lot less intriguing.