Well, maybe this kind of idea is unsuitable for some cases of big_int, but
anyway I should explain the idea better as there seem to be some confusion
(?)

It is a little bit like "small string optimization" and then not at all.

Everything is on stack (until a certain point ?).

So how does it work ? think about "integer operations" - so instead of an
operation overflowing, the result is just held on the stack (but now uses
more stack space).

Im thinking more about smaller operations that you want to be sure does not
overflow for example.

Either its implemented like a "small string optimization" with a fixed
sized stack or a variable sized stack object (not currently possible to
return from a function im pretty sure as it stands).

What im proposing is a "variable stack array" (it is not linked to big_int
! I just thought there might be a relatable use case there).

Do you think there is there a case (at all) for being able to return
"variable sized stackarray" as opposed to fixed size for performance in
some scenario ? (ignoring any difficulties in implementation / language
barriers)
(like, if you don't really know the max size up front this could speed
things up)

Have a lovely day

Rune :)


On Fri, Aug 21, 2026 at 8:58 PM Tiago Freire <tmiguelf_at_[hidden]> wrote:

> Big-int dos not and will not have anything to do with dynamic stack memory.
>
>
>
> I’ve played around with the concept of dynamic stack allocations before, I
> had some applications where that would have been a very cool thing to have
> for performance reasons.
>
>
>
> C “dynamic” arrays are a cool feature, but from an implementation
> perspective I can also see why C++ has not adopt it as it would be
> difficult to combine it with other C++ features and how object lifetime
> works.
>
>
>
> Having said that there really isn’t much to talk about unless you also
> specify what features you would want with this “dynamic array”.
>
>
>
> Are we talking about just like C where the array size can only be set once
> for the entire duration of the function?
>
> Do you want to have dynamic per-scope?
>
> Does dynamic mean can you expand or shrink the array after it has
> originally been set?
>
> Do you want more than one array which has the dynamic property in the same
> function?
>
> Do you want it to be sane for inlining?
>
>
>
> Depending on what you want you need to have very different implementation
> considerations, and some combinations are impossible to implement just
> because of how stacks work.
>
> It has many pitfalls and foot guns.
>
>
>
> And the feature is not that easy to use effectively unless you also have
> features like the ability to consult how much stack you have left, and a
> way to estimate how much stack you will need to safely call functions.
>
> Otherwise, you haven’t so much created a useful stack allocation feature,
> as you have created a way to easily make your application blow up the stack.
>
>
>
> Have you considered what exactly do you mean by “dynamic”? and what things
> you would want to be able to do with it?
>
>
>
>
>
> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> *On Behalf
> Of *Rune Lund Olesen via Std-Proposals
> *Sent:* Friday, August 21, 2026 13:31
> *To:* std-proposals_at_[hidden]
> *Cc:* Rune Lund Olesen <rune.olesen_at_[hidden]>
> *Subject:* [std-proposals] Dynamic stack based array
>
>
>
> 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?
>