On Tue, 2023-08-15 at 09:56 -0400, Julien Villemure-Fréchette via Std-
Proposals wrote:
> I think the intent of alloca in Posix and VLA in C was specifically
> to have automatic cleanup semantics for objects with block scoped
> lifetime. C++ already has the language feature that makes it possible
> to ensure proper cleanup at end of scope, so the need for VLA
> evaporates. If you look closely, the C language doesn't seem to make
> any mention of the stack in the specification of VLAs, I think a pair
> of malloc/free may be a possible implementation.
>
> Neither C or C++ seem to formally require that implementation use a
> stack for automatic allocations. alloca do mention a stack, but it is
> specific to POSIX, not strictly standard C. IMO, If C had a
> requirement that automatic allocations be done on a stack, then I
> think alloca would be part of standard C, and VLAs would never have
> existed

One major difference between alloca and VLAs is that VLAs have the
lifetime of the surrounding block, while alloca allocations are
deallocated at the end of the function (not sure how that interacts
with inlining).

I do think that block scope VLAs had merit, it's just they really
shouldn't have used the C array syntax.

It's also worth mentioning that VLAs with lifetime that cross coroutine
suspension points can't in general be allocated on the stack, neither
in the coroutine frame. In general it would require an additional heap
allocation, which could be optimised away in some special cases.

The last time I tried compilers don't implement VLAs that cross
suspension points (even when VLAs are otherwise supported as a C++
extension). I appreciate that this is probably very low priority.

>
>
> On August 14, 2023 2:43:35 p.m. EDT, Frederick Virchanza Gotham via
> Std-Proposals <std-proposals_at_[hidden]> wrote:
> > On Mon, Aug 14, 2023 at 4:21 PM Thiago Macieira
> > <thiago_at_[hidden]> wrote:
> > >
> > > And what would such function be used for? Please give three
> > > different use-cases
> > > or at least one very strong one that couldn't otherwise be
> > > implemented without
> > > it.
> > >
> >
> >
> > On Page 6 of my paper on Named Return Value Optimisation:
> > http://www.virjacode.com/downloads/nrvo/paper_nrvo_latest.pdf
> >
> > I place a UUID on the stack alongside data which is to be retrieved
> > later. Basically it's a universal way of implementing thread-local
> > storage. So if I want to have a thread_local variable called 'abc',
> > then my strategy is that at every thread entry point, I place the
> > UUID
> > on the stack beside the four bytes 'a' 'b' 'c' '\0' followed by the
> > bytes denoting its value. Then later in the program's execution I
> > can
> > walk the stack backwards til I find the UUID and then I have access
> > to
> > my thread-local data.
> >
> > I can use the function "alloca" at runtime to create more thread-
> > local
> > variables.
> >
> > But more to the point: We should have control of stuff in C++.
> > Every
> > C++ platform has a stack, so give us access to it. Just because I
> > can
> > only come up with one good use for it now doesn't mean someone else
> > won't come up with a use for it later.