[cpp-threads] Some concerns with N2324

[Peter Dimov]

Lawrence Crowl wrote:
> On 7/15/07, Roger Orr <rogero at howzatt.demon.co.uk> wrote:

>> (4) Should we prefer a type to an enumeration?
>>
>> We wondered whether the 'memory_order' could to be a set of
>> typed objects, like with new(nothrow), rather than an enumeration.
>> However this might cause problems with the C API.
>> Or would this be a possible application of strong enum (N2213)?
>
> I would like to ensure that use of the base functions is compilable
> from C.

In N2195 I propose separate types for each ordering constant. It's still 
possible to define them as enums having distinct values for C compatibility 
if the C functions are not intrinsics:

...

The symbols __relaxed, __acquire, __release, __acq_rel and __ordered are 
shown in the synopsis as macros for presentation purposes. The 
implementation is allowed to not define them as macros, subject to the 
requirements below.

...

Constraints

typedef unspecified _Relaxed;
typedef unspecified _Acquire;
typedef unspecified _Release;
typedef unspecified _Acq_Rel;
typedef unspecified _Ordered;

The types _Relaxed, _Acquire, _Release, _Acq_Rel and _Ordered are 
unspecified distinct POD types.

#define __relaxed see below
#define __acquire see below
#define __release see below
#define __acq_rel see below
#define __ordered see below

The symbols __relaxed, __acquire, __release, __acq_rel and __ordered are 
values of type _Relaxed, _Acquire, _Release, _Acq_Rel and _Ordered, 
respectively. It is unspecified whether they are lvalues or rvalues.

[Note: two possible definitions of _Relaxed and __relaxed might be

struct _Relaxed {};
#define __relaxed _Relaxed()

and

enum _Relaxed { __relaxed };

--end note]