On Mon, Aug 14, 2023, at 06:44, Frederick Virchanza Gotham via Std-Proposals wrote:
> To my knowledge, there has never been a C++ compiler for a processor
> that doesn't have a stack.
>
> You can find some C compilers for some very small microcontrollers
> that don't have a stack, but not C++.

> 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:

I'd prefer the standard allow/require unique_ptr, shared_ptr, make_unique, make_shared (and others) to implement automatic storage of T within the size allocated on the stack for the pointer if it meets some criteria. Most implementations of string have small string optimizations similar to that. I don't know if that change can be done without breaking ABI, but this is conceptually a better plan. I don't want developers to use a c++ alloca for arbitrary large objects they think should go on the stack. However for small objects I suspect putting them on the stack can be a performance win without unduly making the stack too large.

For now I'm going to call the criteria unspecified, but people smarter than me are probably thinking about maximum size, if the object needs to be trivial copyable, and other such details that matter. Those may be worth specifying if you write a paper.

A std::stack_ptr (this is a terrible name) similar to unique_ptr except that it can't be moved or copied; could also work. though I'm not sure anyone will use it in practice. The advantage of adding to unique_ptr is if you can get it in a lot of code just becomes better on rebuild.