On Monday, 14 August 2023 11:43:35 PDT Frederick Virchanza Gotham via Std-
Proposals 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.

Since we already have thread_local variables, why do we need to use this
convoluted way of yours? And how does knowing the stack pointer help in that
case?

> I can use the function "alloca" at runtime to create more thread-local
> variables.

See other replies on use or deprecation of alloca.

That also doesn't explain how this function comes into play.

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

No, we shouldn't. The stack is something the compiler uses to implement the
language, including the ability to allocate variables there. There are also
some platforms with two stacks, like Sparc and Itanium. On those, it's
actually entirely possible to make multiple, nested function calls without
touching the regular stack

You made the same claim for the frame pointer, but at least on that case there
was a concrete use-case: backtraces. Of course, in that case, the best
solution is to have a backtrace library instead of getting access to frame
pointers, something most architectures can't do (x86 is actually the exception
here).

In any event, if you don't come up with good use-cases, you won't get the
paper past the committee.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering