Am Freitag, den 11.02.2022, 22:20 +0100 schrieb Corentin via Liaison:
> 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?

Why the grammar?

C++ also does not allow overloading for extern "C". This seems
similar in spirit.


Martin


>
>
>
> >
> > _______________________________________________
> > 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
> >
>
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]p.org
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2022/02/0972.php