On Fri, Feb 11, 2022, 21:55 Jonathan Wakely via Liaison <
liaison_at_[hidden]> wrote:

>
>
> On Fri, 11 Feb 2022, 20:20 Uecker, Martin via Liaison, <
> liaison_at_[hidden]> 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_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2022/02/0971.php
>