3 ms·
> Isn't this the entire reason you shouldn't use the stack for large amounts of data No, the risk of stack overflow would be the typical reason > Stacks unwin
by nu11ptr 3y ago
> Isn't this the entire reason you shouldn't use the stack for large amounts of data
No, the risk of stack overflow would be the typical reason
> Stacks unwind, so you can't pass around pointers to it
Sure you can, you just can't _return_ a reference to something on the stack, but within the data's lifetime you can pass refs to it to other functions
> And the stack is fast because it's often mostly in CPU cache, but that won't be true if you have 100 megs sitting there
The stack is also fast because allocation is free (pointer bump) vs. calling a free list allocator (aka malloc). Cache hits for a large buffer would likely be about the same. If the buffer were small, I would agree on the likelihood of it being in CPU cache.
> This is what the heap is for, it has nothing to do with Rust itself.
In many scenarios moves can and are optimized away, so yes, this has something to do with Rust. I will admit my use case was very contrived and is not a typical use case, but it was very valid (even if not typical).