Date: Fri, 21 Aug 2026 14:05:52 +0100
On 21/08/2026 13:26, Jan Schultke via Std-Proposals wrote:
> I really don't see how std::big_int could work with stack-based allocations. One can easily imagine having a CSV file with some big numbers, and a few hundred thousand rows (or much fewer if the numbers are big enough) exhaust the stack immediately.
>
> Then there are people who literally do calculations with millions of bits, and just a single std::big_int may be larger than all of stack memory.
>
> That being said, I could imagine some RAII wrapper around alloca. It just wouldn't have anything to do with big integers.
I agree with all your points Jan.
To note, there is a way to return structs containing large buffers (fixed sized) I recall. The implementing compiler will move the stack object into the calling frame, so it's already on the stack, and the function called will just fill it up.
Just stack sizes aren't dynamic themselves, safer to use the heap, or a heap pool if fragmentation is a concern.
Kind regards
Jonathan
>
> On Fri, 21 Aug 2026 at 13:32, Rune Lund Olesen via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> wrote:
>
> 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_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>
>
> I really don't see how std::big_int could work with stack-based allocations. One can easily imagine having a CSV file with some big numbers, and a few hundred thousand rows (or much fewer if the numbers are big enough) exhaust the stack immediately.
>
> Then there are people who literally do calculations with millions of bits, and just a single std::big_int may be larger than all of stack memory.
>
> That being said, I could imagine some RAII wrapper around alloca. It just wouldn't have anything to do with big integers.
I agree with all your points Jan.
To note, there is a way to return structs containing large buffers (fixed sized) I recall. The implementing compiler will move the stack object into the calling frame, so it's already on the stack, and the function called will just fill it up.
Just stack sizes aren't dynamic themselves, safer to use the heap, or a heap pool if fragmentation is a concern.
Kind regards
Jonathan
>
> On Fri, 21 Aug 2026 at 13:32, Rune Lund Olesen via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> wrote:
>
> 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_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>
>
Received on 2026-08-21 13:06:01
