Date: Sat, 19 Jun 2021 22:55:19 +0200
On 19/06/2021 22.49, Uecker, Martin wrote:
> Since _Atomic_ref(T) is basically a pointer the
> corresponding C type would then be _Atomic T*.
>
> But would we need to wrap it into a struct
> for ABI compatibility?
It would be the ABI group's job to ensure that C's
hypothetical "_Atomic T *" is equivalent to C++'s
std::atomic_ref<T>.
For x86-64, I think there is no difference between
a plain pointer and a pointer wrapped in a struct
(as its single member). If an ABI makes a difference
here, it would need to carve out a special case for
"_Atomic T *".
>> The question is whether we can/should/want to have a standard-based
>> compatibility story for "atomic reference" or not.
>> We've recently made "_Atomic(T)" the compatibility advice
>> for atomic types in code shared between C and C++. Good.
>
> I am am also not sure. For me _Atomic_ref would be something
> used mainly internally in a library, e.g. where an
> external interface passes a data structure without atomic
> types and then the library wants to apply a concurrent
> algorithm on the existing data structure.
Maybe the -parallel group of WG21 has some opinion here.
Jens
> Since _Atomic_ref(T) is basically a pointer the
> corresponding C type would then be _Atomic T*.
>
> But would we need to wrap it into a struct
> for ABI compatibility?
It would be the ABI group's job to ensure that C's
hypothetical "_Atomic T *" is equivalent to C++'s
std::atomic_ref<T>.
For x86-64, I think there is no difference between
a plain pointer and a pointer wrapped in a struct
(as its single member). If an ABI makes a difference
here, it would need to carve out a special case for
"_Atomic T *".
>> The question is whether we can/should/want to have a standard-based
>> compatibility story for "atomic reference" or not.
>> We've recently made "_Atomic(T)" the compatibility advice
>> for atomic types in code shared between C and C++. Good.
>
> I am am also not sure. For me _Atomic_ref would be something
> used mainly internally in a library, e.g. where an
> external interface passes a data structure without atomic
> types and then the library wants to apply a concurrent
> algorithm on the existing data structure.
Maybe the -parallel group of WG21 has some opinion here.
Jens
Received on 2021-06-19 15:55:30