Dynamic sized arrays on stack

[JonB]

I just discovered the following does work, using g++:

void Class::method()
{
    int array[someFunctionReturningInt()];
}

This surprised me (though pleasantly)!

I tracked down https://stackoverflow.com/questions/1204521/dynamic-array-in-stack and https://stackoverflow.com/questions/43857625/variable-sized-array-on-the-stack. They explain this is not part of C++ but is part of C99, and is supported as an extension to C++ by g++.

Would anybody like to comment on this (e.g. did you know about it)? Or not? ;-) [I only mean about this being allowed, not the other ways I know in which it could be done without requiring this extension.]

[mpergand]

@JonB said in Dynamic sized arrays on stack:

This surprised me (though pleasantly)!

Because like me, you are an old programmer :)
This functionality exists for more than twenty years, i had used it a couple of times since.

[Kent-Dorfman]

Understand that I'm not looking at the spec and it's been a while but

works since storage space is only set up when function is called, but should be considered unsafe since stack size is a compile-time option.

Safer move is to use heap storage and check if allocation succeeds, and I'd actively discourage the above on projects I have authority over..

Actually, I'd go one step further and encourage/enforce use of STL containers such as std::array or std::vector since they clean up after themselves.

[JoeCFD]

@Kent-Dorfman
How much stack usage is too much?
It depends on your operating system. On Windows, the typical maximum size for a stack is 1MB, whereas it is 8MB on a typical modern Linux, although those values are adjustable in various ways.Feb 20, 2016

Why is stack size limited?
This is because stack mostly gets involved into multi-threaded programming and if systems allows stack to grow whenever required then it will be difficult to track each thread at real time cause multi-threaded programs need separate stack for each thread.

[Kent-Dorfman]

@JoeCFD

I think you answered your first question yourself...it is highly system dependent, but I'll add that methods should be small and very limited scope. so, IMHO, there is rarely or ever a reason for a large stack when programming in C++. Recursion, while the favorite child of academics everywhere, is shunned in embedded environments for good reason. While it is algorithmically elegant, it can be costly and even fatal to a running program when the upper bounds of the recursiveness are not known.

Second question? Not sure I understand your points. I'd answer "Why is stack size limited?" in a different way. IOW, avoid the question entirely and stick to the position that in C++ the heap negates the necessity of huge stacks.

[Chris Kawa]

@JonB I would agree with Kent, avoid. It's far too easy to blow past the stack size with this with no warning. With constant sizes you can static check this. With dynamic containers you use the heap, so no problem either. With this you never know.
It's also worth mentioning that it makes stuff like sizeof become a runtime evaluation instead of a constant compile time expression, so another potential downside. I'd say being explicit about your stack usage is always a good thing and leaving it to runtime parameters is asking for trouble.
Besides, it's a compiler extension, so locking you into that particular brand. Something I would avoid too.

@JoeCFD The stack sizes are a per thread resource, yes, but they allocate address space and physical memory pages can be mapped as needed. A modern PC runs hundreds of threads at a time and it's easy to get into GB territory of address space allocations just for stacks, even if physical memory use is a lot lower. Large stacks can be an issue where address space is limited, e.g. on 32 bit systems, or can lead to degraded performance due to large amount of small chunks and fragmentation. The stack size is a balancing act. The defaults are different on different platforms, but you can always set your own size for your app. If you know it's stack hungry or that it barely uses it and you have a lot of threads running you can configure stack size via compiler switches.