C++ Logo

liaison

Advanced search

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

From: Jens Maurer <Jens.Maurer_at_[hidden]>
Date: Sat, 12 Feb 2022 11:43:47 +0100
On 12/02/2022 11.16, Jā‚‘ā‚™ā‚› Gustedt wrote:
> Jens,
>
> 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?

I think compilers could already warn about those situations
(and also about the thread_local thing).

extern "C" {
  struct S {
    S(); // warning: member function in C-compatible struct
    int x;
  };
};

Maybe we should solicit implementation experience with warnings in
this area, to estimate the blast radius of adding restrictions to
the language. The willingness of compilers to provide such warnings
might also inform the cost/benefit estimation of the committee.

Jens

Received on 2022-02-12 10:43:52