I share Jens’ view.

Olivier

________________________________
From: Parallel <parallel-bounces_at_[hidden]> on behalf of Jens Maurer via Parallel <parallel_at_[hidden]>
Sent: Saturday, June 19, 2021 5:24 AM
To: parallel_at_[hidden]; WG14/WG21 liaison mailing list
Cc: Jens Maurer; Uecker, Martin; Aaron Ballman
Subject: Re: [isocpp-parallel] [wg14/wg21 liaison] atomics in C++

External email: Use caution opening links or attachments


> 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.

>> 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".
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 *".

Jens
_______________________________________________
Parallel mailing list
Parallel_at_[hidden]
Subscription: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fparallel&amp;data=04%7C01%7Cogiroux%40nvidia.com%7Cf4adf7fdc9954f9d2d0f08d9331d361f%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637597022830855118%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=KtKDjA80uUVhhU%2FyPXnqdI4Q%2BBcpC3kfXgAtrDqEux0%3D&amp;reserved=0
Link to this post: https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fparallel%2F2021%2F06%2F3643.php&amp;data=04%7C01%7Cogiroux%40nvidia.com%7Cf4adf7fdc9954f9d2d0f08d9331d361f%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637597022830855118%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=jUTe3S9XjbQRrV%2FjdAgMUuRQsbIYDAvretfO%2BOPLil0%3D&amp;reserved=0