[cpp-threads] Comments on D3193 atomics C compat

[Lawrence Crowl]

On 11/12/10, Anthony Williams <anthony at justsoftwaresolutions.co.uk> wrote:
> I've been reading the latest C compatibility paper D3193, and the notes
> on the reflector.
>
> It is unfortunate that C are insisting on keeping the "_Atomic int"
> style, as this requires a keyword and cannot be built in the library on
> top of existing compiler support for atomics with a different syntax.
> Both _Atomic(int) and atomic<int> can be built on the support from an
> existing compiler, whatever the syntax is.
>
> I do not see _Atomic(x) in the latest draft of D3193. Has it been
> removed? If so, why? Are we relying on the atomic_xyz typedefs for C
> compatibility?

It has been removed.  The C committee is just a little bit unsettled
right now, and we are sure we can be compatible at that level.

>
> I am not sure how it helps C compatibility to make it implementation
> defined whether or not atomic_int is a typedef for atomic<int> or a base
> class of atomic<int>.

We would like _Atomic int /* or whatever the syntax becomes */ to
be the same type as atomic<int>.  If C has the productive syntax,
then we do not want the base relationship.  If C does not have the
productive syntax, then we want the base relationship.

> That can easily lead to non-portable C++ --- if I
> write my code on an implementation where atomic_int is a typedef then I
> can freely mix atomic<int> and atomic_int all over the place, but this
> may not then compile on an implementation where atomic_int is a base class.

That was understood.  I find it unfortunate, but I think it's the
best we could get for the time being.  Later we may be able to
refine it.

-- 
Lawrence Crowl