Which advantages does this proposal have, compared to a stack array, with a compile-time constant maximum specified (and allocated)?

The stack assigned to the program has to be large enough anyway to hold the complete call-tree.

There may be situations, where either the calls are more unpredictable or one has several dynamic array variables on the stack, but who would really risk their program crashing just not to have to use the heap?

I think there were practical reasons, why dynamic arrays on the stack are not a thing in the C++ standard:

 - ABI

 - exceptions

 - correct destruction and freeing of objects

 - modern security features

I am sure there are some old discussion on this mailing list, which go deeper into technical arguments.

-----Ursprüngliche Nachricht-----
Von: Rune Lund Olesen via Std-Proposals <std-proposals@lists.isocpp.org>
Gesendet: Fr 21.08.2026 13:32
Betreff: [std-proposals] Dynamic stack based array
An: std-proposals@lists.isocpp.org;
CC: Rune Lund Olesen <rune.olesen@gmail.com>;

Looking at the recent Big-int proposal, this is or could be a case for C++ to provide a dynamically sized array (ie. stack allocated if on the stack).

 

C has a dynamically allocated array type and it is possible to program something like this by hand in C maybe with MACRO usage inside a function - but it is contained to that function.

 

Returning dynamically sized objects is not even possible with current calling conventions - but maybe there exists some tricks to get around that (eg. before returning; perhaps rearrange the stack and then move the stackpointer once returned).

 

Now there would be some type of tracking the size as well and it should be possible to specify staticly how many bytes/bits should be used for that....

 

Right now the closest there is, is some types of arena put on the stack to start..

 

What do you think?

-- 
 Std-Proposals mailing list
 Std-Proposals@lists.isocpp.org
 https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals