Am Samstag, den 19.06.2021, 14:24 +0200 schrieb Jens Maurer:
> > On Sat, Jun 19, 2021 at 7:17 AM Uecker, Martin via Liaison
> > <liaison_at_[hidden]> wrote:
> > > For compatibility, there are two things required:
> > >
> > > 1. Compatible syntax for headers
> > > 2. ABI compatibility
> > >
> > > Regarding the first point, in C we have the atomic_XXX types and
> > > also the _Atomic(T) type specifier (C11), which were both designed
> > > together with WG21 with compatibility in mind. The only thing which
> > > still was missing is the _Atomic(T) macro in C++. This seems now part
> > > of C23++ [1]. So the compatibility story seems finally complete
> > > and we can now write things like this (thank you WG21!):
> > >
> > > #ifdef __cplusplus
> > > extern "C" {
> > > #endif
> > >
> > > #include <stdatomic.h>
>
> I'd put the #include outside of the "extern C" bracket.
>
> > > void foo(_Atomic(int) *x);
>
> Before C++23, you could have written
>
> void foo(atomic_int *x);
>
> instead.
>
> > > With respect to ABI, there is still the issue that _Atomic(T) types
> > > are not compatible between implementations even within C++:
>
> The ABI story of atomics is a sad one, but nothing the language
> standard can fix.

Yes, although I think one could try to be more
careful when adding new types next time.

> > > Finally, there is the _Atomic qualifier in C which is currently
> > > a different way to specifiy the same type as _Atomic(T).
> > > From the C side, this is problematic as it is at the same
> > > time completely useless because it provides no new functionality
> > > and confusing as it does not work in he same way as any
> > > other qualifier.
> > >
> > >
> > > But the _Atomic qualifier in C also has no impact on C/C++
> > > compatibility at all as it is not supported in C++ (similar
> > > to how std::atomic<T> template syntax is not a compatibility
> > > problem as this is not supported in C).
>
> I'm not aware of any effort that would make "_Atomic T" valid
> in C++ (nor would I be in favor of such endeavor).
> The compatibility advice is to use "_Atomic(T)" instead.
> So, C is free to do whatever it wants with "_Atomic T".

Good.

> However, if C comes up with a new meaning of "_Atomic T", we
> should still understand whether that syntax would be agreeable
> to C++ for that new meaning.
>
> For example, I'd probably prefer a library macro
> "_Atomic_ref(T)" for the C/C++ compatibility story over
> supporting in C++ "_Atomic int *" with the meaning "atomic access
> to a plain int", including core language conversion from "int*"
> to "_Atomic int *".

This was my original idea, although I now think it
might be better to deprecate _Atomic and introduce
something new. For C, a qualifier seems to be
exactly the right mechanism on the language level.
(I will also not argue against the use of templates
in C++.) We could then add a _Atomic_ref macro if this
makes sense.

Martin