4 ms·

Dynamic data structures by their nature have to be allocated to the heap. What I mean by "prefers the stack" is that you don't have to make a managed ref and de

Dynamic data structures by their nature have to be allocated to the heap. What I mean by "prefers the stack" is that you don't have to make a managed ref and dereference a managed pointer type. You just make a `seq[int]`, use it as a `seq[int]`, and pass it as a `seq[int]`, just like stack data. Behind the scenes, it has a unique scoped pointer with no mental overhead.

jitl 3y ago
Sounds like a vector/array/list in any other language after C++, like Go slice, Java ArrayList, Javascript array, Python list, Rust vec. Is there something I'm missing?
- gcoakes 3y ago
  I think they're discussing the lifetime of that heap data, not whether the data is heap allocated.
  - chc 3y ago
    I don't see them drawing any distinctions from C++ or Rust there either. It really sounds to me like most of their low-level experience is in C, where the contrasts they appear to be drawing really do apply.
kragen 3y ago
it depends on what you mean by 'dynamic' and 'stack'; certainly, outside of nim, you can allocate a list of, say, integers entirely on a stack in any of the following cases: - 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

jitl 3y ago

Sounds like a vector/array/list in any other language after C++, like Go slice, Java ArrayList, Javascript array, Python list, Rust vec. Is there something I'm missing?

gcoakes 3y ago
I think they're discussing the lifetime of that heap data, not whether the data is heap allocated.
- chc 3y ago
  I don't see them drawing any distinctions from C++ or Rust there either. It really sounds to me like most of their low-level experience is in C, where the contrasts they appear to be drawing really do apply.

kragen 3y ago

it depends on what you mean by 'dynamic' and 'stack'; certainly, outside of nim, you can allocate a list of, say, integers entirely on a stack in any of the following cases: - 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