This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.

### 1461. Rename all `ATOMIC_*` macros as `STD_ATOMIC_*`

Section: 31 [atomics] Status: NAD Submitter: Canada Opened: 2010-08-25 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [atomics].

View all issues with NAD status.

Discussion:

Addresses CA-1

All `ATOMIC_`... macros should be prefixed with `STD_` as in `STD_ATOMIC_`... to indicate they are `STD` macros as other standard macros. The rationale that they all seem too long seems weak.

[2011-03-06: Daniel adapts suggested wording to N3242 and comments]

I suggest to declare this issue as NAD. Reason for this suggestion is, that C1x is currently going to suggest exactly the same macros as additions to header `<stdatomic.h>`, therefore C++0x should not define a whole new set. I'm making this suggestion with the understanding that C1x is intending to keep in sync in this regard. For example, the most recent draft of C1x does contain the macro `ATOMIC_ADDRESS_LOCK_FREE` which has recently been removed from the C++ working draft.

[2011-03-24]

Rationale:

C is not going to change the name of these macros, and it is important they have the same name for compatibility

Proposed resolution:

1. Change sub-clause 31.2 [atomics.syn] as indicated:

   >     [..]
   >     // [atomics.lockfree], lock-free property
   >     #define STD_ATOMIC_CHAR_LOCK_FREE unspecified
   >     #define STD_ATOMIC_CHAR16_T_LOCK_FREE unspecified
   >     #define STD_ATOMIC_CHAR32_T_LOCK_FREE unspecified
   >     #define STD_ATOMIC_WCHAR_T_LOCK_FREE unspecified
   >     #define STD_ATOMIC_SHORT_LOCK_FREE unspecified
   >     #define STD_ATOMIC_INT_LOCK_FREE unspecified
   >     #define STD_ATOMIC_LONG_LOCK_FREE unspecified
   >     #define STD_ATOMIC_LLONG_LOCK_FREE unspecified

   >     // [atomics.types.operations.req], operations on atomic types
   >     #define STD_ATOMIC_VAR_INIT(value) see below
   >     [..]

2. Change 31.5 [atomics.lockfree] p. 1 as indicated:

   >     #define STD_ATOMIC_CHAR_LOCK_FREE implementation-defined
   >     #define STD_ATOMIC_CHAR16_T_LOCK_FREE implementation-defined
   >     #define STD_ATOMIC_CHAR32_T_LOCK_FREE implementation-defined
   >     #define STD_ATOMIC_WCHAR_T_LOCK_FREE implementation-defined
   >     #define STD_ATOMIC_SHORT_LOCK_FREE implementation-defined
   >     #define STD_ATOMIC_INT_LOCK_FREE implementation-defined
   >     #define STD_ATOMIC_LONG_LOCK_FREE implementation-defined
   >     #define STD_ATOMIC_LLONG_LOCK_FREE implementation-defined

   > > 1 The `STD_ATOMIC_..._LOCK_FREE` macros indicate the lock-free property of the corresponding atomic types, [..]

3. Change 99 [atomics.types.operations.req] p. 6 as indicated:

   >     #define STD_ATOMIC_VAR_INIT(value) see below

   > > 5 Remarks: The macro expands to a token sequence suitable for constant initialization an atomic variable of static storage duration of a type that is initialization-compatible with value. [ Note: This operation may need to initialize locks. — end note ] Concurrent access to the variable being initialized, even via an atomic operation, constitutes a data race. [ Example:

   > > >     atomic<int> v = STD_ATOMIC_VAR_INIT(5);

   > > — end example ]

4. Change 31.10 [atomics.flag] p. 1+4 as indicated:

   >     namespace std {
   >       [..]
   >       #define STD_ATOMIC_FLAG_INIT see below
   >     }

   > > [..] 4 The macro `STD_ATOMIC_FLAG_INIT` shall be defined in such a way that it can be used to initialize an object of type `atomic_flag` to the clear state. For a static-duration object, that initialization shall be static. It is unspecified whether an unitialized `atomic_flag` object has an initial state of set or clear. [ Example:

   > > >     atomic_flag guard = STD_ATOMIC_FLAG_INIT;

   > > — end example ]