I'll answer the original question (ie. stack vs. heap) first:
Stack has basically two advantages and one disadvantage. The first advantage is that you save a register, because the compiler doesn't need to track an extra pointer (ie. usually it can just offset from the stack pointer instead). The second advantage is that the top of stack is usually likely to stay in cache (and some people have speculated that CPUs even do some special magic to make this happen, although this might be urban legend as well), so you might save a bunch of cache misses.
The disadvantage is that the amount of stack space available is rather unpredictable and it might at times be less than what you expect. For example, on Windows the default stack size for threads created by CreateThread is usually 1MB! That's plenty even for most recursive algorithms with a couple of local variables, but not a whole lot if you start allocating a bunch of large buffers. What's worse, the errors you end up when you exhaust the stack space are sometimes quite annoying to track down. The key here is that unless you created the thread yourself, you really don't know.
As a rule of thumb, I'd usually allocate from the heap anything that measures in the dozens of kilobytes or more. At that point the potential cache advantages of stack are unlikely to be relevant anymore and you save yourself the trouble of having to think about the implications of potentially finite stack size.
[edit: also NEVER use anything like alloca() that let's you do dynamic allocation from the stack; that's just asking for trouble and you'll end up regretting it sooner or later]
Nowhk wrote: ↑
Wed Jun 12, 2019 2:29 am
3) This is an alive question which I didn't find any answers in the past years: is vector really faster than raw pointers?
The answer is no, but it can be as fast as raw pointers.
Basically, unless you have additional debug checks enabled in your particular STL implementation (which some of them provide), then operator should optimise to a regular pointer access. You can also get the raw pointer with data() in case you need to pass the array to some function that expects a raw pointer, but really there's no reason to avoid operator unless you really just need the pointer.
There's also the at() method, which is like operator but throws on out of bounds access. This one is obviously slightly slower, unless the compiler manages to optimise the bounds checking away.
The cool thing about vectors though is that even the methods that change the size is real-time safe as long as you reserve() an upper bound in advance, because vector never reallocates storage unless it grows larger than the reserved size or you explicitly call shrink_to_fit(). This means is that you can also use vectors also in situations where you might need a variable sized buffer, just call resize() (or even push_back/pop_back) as required and it won't ever reallocate unless your reserve() was too conservative (in which case you risk a glitch with reallocation and usually this is a better "fail-safe" than randomly trashing memory).