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});
        }
        else
        {
            ...

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.