Isn’t that the same as a C++ vector or map on stack? They allocate internally as needed, and the whole container is destroyed when it goes out of scope.
Isn’t that the same as a C++ vector or map on stack? They allocate internally as needed, and the whole container is destroyed when it goes out of scope.
So now the language can credibly claim the same as c++ - no room left closer to the metal. But it's packaged in a much nicer syntax (imho), and has features like macros which we can expect I'm C++ in maybe 10 years, if we're lucky.
That doesn't happen by default in C++ either.
std::vector<int> some_seq{1, 2, 3, 4, 5, 7};
std::vector some_seq{1, 2, 3, 4, 5, 7};
nowadays (for a value of nowadays that is 5 years old for GCC and 6 years old for Clang)the relevant docs are here: https://nim-lang.org/docs/destructors.html
- the size of the list is known when you create a stack frame, as in c:
int xs[n] = {0};
- when the list grows, it grows in that subroutine and not some callee, for example using alloca();- the list is built on a stack that isn't the one you have to pop your return address off of; examples include perl's data stack, ada's secondary stack, forth's operand stack, forth's dictionary, or an mlkit region. in these cases you can even return the dynamically built structure to a caller;
- each new callee adds some fixed number of items to a linked list, such as, in c
void with_fill(color *c,
env *e,
void (*cb)(void*, env*),
void *userdata)
{
env ne = {
.prop = PROP_FILL_COLOR,
.val = c,
.parent = e };
cb(userdata, &ne);
}
look ma, no heap"var data: MyObject" is on the stack. "var arr: array[1000, MyObject]" is allocated on the stack sequentially.
Only dynamic seq or ref types use the heap by default.