C++ Logo


Advanced search

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

From: Jₑₙₛ Gustedt <jens.gustedt_at_[hidden]>
Date: Sat, 12 Feb 2022 11:16:24 +0100

on Sat, 12 Feb 2022 10:50:28 +0100 you (Jens Maurer via Liaison
<liaison_at_[hidden]>) wrote:

> So far, "extern C" imposes only additional restrictions
> on the contained stuff (namespaces are ignored when
> determining naming conflicts; thread_local supports only
> types with trivial construction and destruction).
> This seems plausible to me.

Couldn't there be a similar restriction for *all* objects with C
linkage? Why restrict this safety check to thread local variables.

Same for structure or union types that are specfied to have C linkage?

> Changing syntax inside "extern C" is going one step too far
> for me. Whether C++ wants to support "_Complex T" as an
> alias for std::complex<T> should be a global feature, to be
> decided on its own merits.
> For atomics, my understanding is that the compatibility
> story is already quite good, because you can write _Atomic(T)
> in both languages.
> For multi-dimensional VM-types, I'm not sure those can be
> represented with an mdspan at all.

Yes, all of these would probably need much more discussion and
coordination between the committees, and are much less clear.


:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::

Received on 2022-02-12 10:16:26