Has this ever been proven to be a problem in practice, given that a program's stack is typically limited in size? Would the recommended workaround (if this was a problem) be to change variables to use heap instead?
Has this ever been proven to be a problem in practice, given that a program's stack is typically limited in size? Would the recommended workaround (if this was a problem) be to change variables to use heap instead?
Allocation more or less everything on the heap (i.e. using the stack only for calls and returns) is something that's done out of necessity in exclusively GC'd languages, like Java or Python.
I'm just wondering if the extra emphasis on stack allocation has created issues; this article doesn't cover the allocation of Strings or Vecs (wrapping them in RC and ARC boxes), and most other references on the net are a few years old now.
As in C++, these are small stack structures (a few words, IIRC it's 3 for Vec, and String is backed by a Vec) pointing to a heap-allocated buffer.
That was my first thought as well when I read that passage. Do you know why the author might have felt the need to state this specific in the context of Rust then?
Note that it only applies to local variables. If you have a primitive inside an object then it's allocated on the heap as part of the outer object.
It is occasionally a problem. For example, when writing my old emulator, I statically allocated the system's RAM (which has a fixed size) on the stack at first before thinking better of it and moving it to the heap. But such situations are uncommon.