C++ Logo

liaison

Advanced search

Re: [wg14/wg21 liaison] On _Thread_local for better C++ interoperability with C (P2478)

From: Jonathan Wakely <cxx_at_[hidden]>
Date: Fri, 11 Feb 2022 20:54:55 +0000
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.

Received on 2022-02-11 20:55:08