[cpp-threads] Some concerns with N2324

[Lawrence Crowl]

On 7/16/07, Peter Dimov <pdimov at mmltd.net> wrote:
> Lawrence Crowl wrote:
> > On 7/16/07, Peter Dimov <pdimov at mmltd.net> wrote:
>
> ...
>
> >> [Note: two possible definitions of _Relaxed and __relaxed might be
> >>
> >> struct _Relaxed {};
> >> #define __relaxed _Relaxed()
> >>
> >> and
> >>
> >> enum _Relaxed { __relaxed };
> >>
> >> --end note]
> >
> > Syntactically, this works, but the ABI for the two are
> > generally not the same, and we need the same ABI.
>
> The ABI for the constraints is only a concern when one has a C function
>
> void f( memory_order m, ... );
>
> that is also used from C++ (where it's declared extern "C") - or vice versa.
> N2195 pretty much prohibits this use case since there is no containing
> 'memory_order' type to which all constraints are convertible, and since
> there is no overloading in C, there's no need to pass a constraint argument
> at all.
>
> I don't know how important is this use case in practice. Most existing
> atomic libraries support no constraint arguments at all (at least in its C
> portion) so they obviously don't deliver the functionality. The function is
> hard to inline, so the performance is likely to suffer on most platforms.

The use case is what I'm trying to support, in large part because I cannot
predict all of what programmers will want to do.

> The atomic_* functions themselves can map to different names in C and C++
> mode (if they exist as functions at all; N2195 says that they need not, not
> sure about N2324 - I don't see a prohibition in it to take their addresses,
> so intrinsics and macros seem outlawed).

You're right, and I don't have strong feelings here.  I need to check on
what C type-generic macros have to say about the topic.

-- 
Lawrence Crowl