C++ Logo


Advanced search

Re: [std-proposals] C++ never had a compiler without a stack

From: David Brown <david_at_[hidden]>
Date: Wed, 16 Aug 2023 15:37:57 +0200
On 16/08/2023 14:10, Marcin Jaczewski via Std-Proposals wrote:
> śr., 16 sie 2023 o 13:42 David Brown via Std-Proposals
> <std-proposals_at_[hidden]> napisał(a):
>> On 15/08/2023 19:25, Alejandro Colomar via Std-Proposals wrote:
>>> Hi Andrey,
>>> On 2023-08-15 18:41, Andrey Semashev via Std-Proposals wrote:
>>>> On 8/14/23 17:31, Alejandro Colomar via Std-Proposals wrote:
>>>>> Hello Frederick,
>>>>> On 2023-08-14 13:44, Frederick Virchanza Gotham via Std-Proposals wrote:
>>>>>> And also how about we standardise the function "alloca" which allows
>>>>>> us to allocate bytes on the stack? For those not familiar with
>>>>>> 'alloca', here's the Linux manual entry:
>>>>>> https://man7.org/linux/man-pages/man3/alloca.3.html
>>>>>> And here's a quick excerpt from that manual page
>>>>>> The alloca() function allocates size bytes of space in the stack
>>>>>> frame of the caller. This temporary space is automatically freed
>>>>>> when the function that called alloca() returns to its caller.
>>>>>> Because it allocates from the stack, it's faster than malloc
>>>>>> and free. In certain cases, it can also simplify memory
>>>>>> deallocation in applications that use longjmp or siglongjmp.
>>>>> Now that C has VLAs, alloca(3) is being removed from many projects.
>>>>> In most cases, there's no guarantee that the size will fit in the
>>>>> stack, and so one should use malloc(3). In the few cases where the
>>>>> size is known to be small, VLAs are preferable. In fact, this is
>>>>> exactly what glibc is doing at the moment: replace all calls to
>>>>> alloca(3) by either malloc(3) or VLAs.
>>>> I think the general direction is exactly the opposite - to get rid of
>>>> VLAs wherever possible. They are also not supported in C++.
>>> Hmm, I've revisited the thread I was remembering[1], and yeah, they're
>>> replacing alloca(3) by a fixed-size array. I was remembering wrong.
>>> Yeah, fixed-size arrays or malloc(3) should be preferable to alloca(3).
>> Why do you say that?
>> Fixed-size arrays are great when you know a fixed size. But if you only
>> know an upper bound, then you might be wasting significant stack space -
>> and that translates to wasted cache, and slower results. This must be
>> balanced against any extra code generated to handle a VLA or alloca().
>> So if the upper bound is known to be small, go for a fixed-size array.
>> And if the size is fixed (and small enough), then a fixed size array is
>> definitely better than other options - but in C, remember that some
>> things that would be fixed size arrays in C++ are technically VLAs in C.
>> (Such VLAs with compile-time known size are as efficient as true
>> fixed-size arrays.)
> In C++ there is another solution that is something between static array and
> VLA:
> ```
> template<typename T, typename F>
> void TempArray(int size, F func)
> {
> if (size < 10)
> {
> T t[10];
> func(std::span{ t, t + size});
> }
> else if (size < 100)
> {
> T t[100];
> func(std::span{ t, t + size});

That is hardly an alternative to VLA's ! And if "size" is unknown at
compile time, it is not improbable that a compiler would simplify the
code to :

        if (size < 10000)
            T t[10000];
            func(std::span{ t, t + size});

in order to skip all these tests, branches, and duplicate code.

I understand why C++ does not, despite several attempts, have VLA's or
alternative safer container-style stack-allocated run-time sized arrays.
  But code like this is not a reasonable alternative IMHO.

Received on 2023-08-16 13:38:06