On Fri, Feb 11, 2022, 21:55 Jonathan Wakely via Liaison <liaison@lists.isocpp.org> wrote:


On Fri, 11 Feb 2022, 20:20 Uecker, Martin via Liaison, <liaison@lists.isocpp.org> wrote:
Am Freitag, den 11.02.2022, 20:45 +0100 schrieb Corentin via Liaison:

...
>
> Another idea, brought up by Tom, was the idea of some syntax at point of
> use:
> extern "C" thread_local S foo;
>
> But the compiler still needs to create code for initialization and
> destruction. I guess in that case, the compiler can eagerly run the
> initialization, and that solves the not-yet-initialized problem C faces.

Initialization for each thread?

At thread creation time, but that doesn't sound great to me.




I think the most intuitive behavior is if

extern "C" thread_local S foo;

behaves just like _Thread_local would do in C and a C++ type
that requires non-trivial initialization would simply not
be allowed, i.e. it behaves like _Thread_local in clang
in c++ mode.

I agree. Why would you be trying to use a type with non-trivial init in common code defined in a header, but so that it does different things in C and C++? If you need non-trivial init, define the code in a separate C++ transition unit, not in a header.

But by that logic, do we want to change the grammar of C++ for this narrow scenario?






_______________________________________________
Liaison mailing list
Liaison@lists.isocpp.org
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
Link to this post: http://lists.isocpp.org/liaison/2022/02/0971.php