1. Abstract
We propose deprecating most of
. See §3 Wording for the details.
The proposed deprecation preserves the useful parts of
, and removes
the dubious / already broken ones. This paper aims at breaking at compiletime
code which is today subtly broken at runtime or through a compiler update. The
paper might also break another type of code: that which doesn’t exist. This
removes a significant footgun and removes unintuitive corner cases from the
languages.
The first version of this paper, [P1152R0], has extensive background information which is not repeated here:
See [P1382R0] for the followup paper on
/
requested by SG1.
2. Edit History
2.1. r0 → r1
[P1152R0] was seen by SG1 and EWG in San Diego. This update does the following:

Remove background information from the paper.

Follow the guidance from SG1 and EWG, based on the polls below.
Poll  Group  SF  F  N  A  SA  Outcome 

Deprecate compound operations (including and ) on scalar types (arithmetic, pointer, enumeration).
 SG1  4  19  3  0  0  ✅ 
Deprecate compound operations (including and ) on scalar types (arithmetic, pointer, enumeration).
 EWG  4  9  4  0  0  ✅ 
Deprecate usage of assignment chaining on scalar types (arithmetic, pointer, enumeration, pointer to members, ).
 SG1  6  15  3  0  0  ✅ 
Deprecate usage of assignment chaining on scalar types (arithmetic, pointer, enumeration, pointer to members, ).
 EWG  6  9  3  0  0  ✅ 
SG1 would be OK if we deprecated qualified member functions (pending separate decision on what we do with atomic).
 SG1  1  5  10  4  3  ❌ 
EWG would be OK if we deprecated qualified member functions (pending separate decision on what we do with atomic).
 EWG  2  7  7  1  0  ✅ 
SG1 would be OK if we deprecated partial template specializations, overloads, or qualified member functions in the STL for all but the atomic, , and type traits ( , , etc) parts of the Library.
 SG1  1  9  6  2  0  ✅ 
EWG would be OK if we deprecated partial template specializations, overloads, or qualified member functions in the STL for all but the atomic, , and type traits ( , , etc) parts of the Library.
 EWG  1  11  9  0  0  ✅ 
Deprecate member functions of atomic in favor of new template partial specializations which will only declare load, store, and only exist when is true.
 SG1  2  1  1  11  2  ❌ 
Deprecate member functions of atomic in favor of new template partial specializations which will only declare load, store, RMW, and only exist when is true.
 SG1  4  7  3  3  0  ✅ 
Deprecate member functions of atomic in favor of new template partial specializations which will only declare load, store, RMW, and only exist when is true.
 EWG  2  9  3  0  0  ✅ 
Deprecate member functions of atomic in favor of new template partial specializations which will only declare load, store, RMW.
 SG1  0  0  0  10  7  ❌ 
SG1 would be OK if we deprecated toplevel parameters.
 SG1  6  9  6  2  1  ✅ 
EWG would be OK if we deprecated toplevel parameters.
 EWG  6  9  6  0  0  ✅ 
EWG would be OK if we deprecated toplevel const parameters.  EWG  0  2  5  8  8  ❌ 
SG1 would be OK if we deprecated toplevel return values.
 SG1  6  9  4  2  0  ✅ 
EWG would be OK if we deprecated toplevel return values.
 EWG  6  6  5  0  0  ✅ 
EWG would be OK if we deprecated toplevel const return values.  EWG  2  3  3  5  5  ❌ 
SG1 interested is interested in hearing about / free functions in a separate paper, given that time is limited and we could be doing something else.
 SG1  0  17  4  3  0  ✅ 
EWG interested is interested in hearing about / free functions in a separate paper, given that time is limited and we could be doing something else.
 EWG  2  11  4  1  0  ✅ 
3. Wording
3.1. Program execution [intro.execution]
No changes.
Accesses through
glvalues are evaluated strictly according to the rules of the abstract machine.
volatile Reading an object designated by a
glvalue, modifying an object, calling a library I/O function, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment. Evaluation of an expression (or a subexpression) in general includes both value computations (including determining the identity of an object for glvalue evaluation and fetching a value previously assigned to an object for prvalue evaluation) and initiation of side effects. When a call to a library I/O function returns or an access through a
volatile glvalue is evaluated the side effect is considered complete, even though some external actions implied by the call (such as the I/O itself) or by the
volatile access may not have completed yet.
volatile
3.2. Data races [intro.races]
No changes.
Two accesses to the same object of type
volatile do not result in a data race if both occur in the same thread, even if one or more occurs in a signal handler. For each signal handler invocation, evaluations performed by the thread invoking a signal handler can be divided into two groups A and B, such that no evaluations in B happen before evaluations in A, and the evaluations of such
std :: sig_atomic_t
volatile objects take values as though all evaluations in A happened before the execution of the signal handler and the execution of the signal handler happened before all evaluations in B.
std :: sig_atomic_t
3.3. Forward progress [intro.progress]
No changes.
The implementation may assume that any thread will eventually do one of the following:
terminate,
make a call to a library I/O function,
perform an access through a
glvalue, or
volatile perform a synchronization operation or an atomic operation
During the execution of a thread of execution, each of the following is termed an execution step:
termination of the thread of execution,
performing an access through a
glvalue, or
volatile completion of a call to a library I/O function, a synchronization operation, or an atomic operation.
3.4. Class member access [expr.ref]
No changes.
Abbreviating postfixexpression.idexpression as
,
E1 . E2 is called the object expression. If
E1 is a bitfield,
E2 is a bitfield. The type and value category of
E1 . E2 are determined as follows. In the remainder of [expr.ref], cq represents either
E1 . E2 or the absence of
const and vq represents either
const or the absence of
volatile . cv represents an arbitrary set of cvqualifiers.
volatile
If
is a nonstatic data member and the type of
E2 is “cq1 vq1 X”, and the type of
E1 is “cq2 vq2 T”, the expression designates the named member of the object designated by the first expression. If
E2 is an lvalue, then
E1 is an lvalue; otherwise
E1 . E2 is an xvalue. Let the notation vq12 stand for the “union” of vq1 and vq2; that is, if vq1 or vq2 is
E1 . E2 , then vq12 is
volatile . Similarly, let the notation cq12 stand for the “union” of cq1 and cq2; that is, if cq1 or cq2 is
volatile , then cq12 is
const . If
const is declared to be a
E2 member, then the type of
mutable is “vq12 T”. If
E1 . E2 is not declared to be a
E2 member, then the type of
mutable is “cq12 vq12 T”.
E1 . E2
3.5. The cvqualifiers [dcl.type.cv]
No changes.
The semantics of an access through a
glvalue are implementationdefined. If an attempt is made to access an object defined with a
volatile qualified type through the use of a non
volatile glvalue, the behavior is undefined.
volatile [ Note:
is a hint to the implementation to avoid aggressive optimization involving the object because the value of the object might be changed by means undetectable by an implementation. Furthermore, for some implementations,
volatile might indicate that special hardware instructions are required to access the object. See [intro.execution] for detailed semantics. In general, the semantics of
volatile are intended to be the same in C++ as they are in C. —end note ]
volatile
3.6. Functions [dcl.fct]
Modify as follows.
The parameterdeclarationclause determines the arguments that can be specified, and their processing, when the function is called. [ Note: The parameterdeclarationclause is used to convert the arguments specified on the function call; see [expr.call] —end note ] If the parameterdeclarationclause is empty, the function takes no arguments. A parameter list consisting of a single unnamed parameter of nondependent type
is equivalent to an empty parameter list. Except for this special case, a parameter shall not have type cv
void . A parameter’s declarator shall only allow
void as its parametersandqualifiers's cvqualifierseq. If the parameterdeclarationclause terminates with an ellipsis or a function parameter pack, the number of arguments shall be equal to or greater than the number of parameters that do not have a default argument and are not function parameter packs. Where syntactically correct and where "
const " is not part of an abstractdeclarator, "
... " is synonymous with "
, ... ".
... [...]
The type of a function is determined using the following rules. The type of each parameter (including function parameter packs) is determined from its own declspecifierseq and declarator. After determining the type of each parameter, any parameter of type "array of
" or of function type
T is adjusted to be "pointer to
T ". After producing the list of parameter types, any toplevel cvqualifiers modifying a parameter type are deleted when forming the function type. The resulting list of transformed parameter types and the presence or absence of the ellipsis or a function parameter pack is the function’s parametertypelist.
T [...]
Functions shall not have a return type of type array or function, although they may have a return type of type pointer or reference to such things. There shall be no arrays of functions, although there can be arrays of pointers to functions.
Functions shall not have aqualified return type.
volatile
3.7. Nonstatic member functions [class.mfct.nonstatic]
No changes.
A nonstatic member function may be declared
,
const , or
volatile . These cvqualifiers affect the type of the
const volatile pointer. They also affect the function type of the member function; a member function declared
this is a
const member function, a member function declared
const is a
volatile member function and a member function declared
volatile is a
const volatile member function.
const volatile
3.8. The this pointer [class.this]
No changes.
In the body of a nonstatic member function, the keyword
is a prvalue expression whose value is the address of the object for which the function is called. The type of
this in a member function of a class
this is
X . If the member function is declared
X * , the type of
const is
this , if the member function is declared
const X * , the type of
volatile is
this , and if the member function is declared
volatile X * , the type of
const volatile is
this .
const volatile X *
semantics apply in
volatile member functions when accessing the object and its nonstatic data members.
volatile
3.9. Constructors [class.ctor]
No changes.
A constructor can be invoked for a
,
const or
volatile object.
const volatile and
const semantics are not applied on an object under construction. They come into effect when the constructor for the most derived object ends.
volatile
3.10. Destructors [class.dtor]
No changes.
A destructor is used to destroy objects of its class type. The address of a destructor shall not be taken. A destructor can be invoked for a
,
const or
volatile object.
const volatile and
const semantics are not applied on an object under destruction. They stop being in effect when the destructor for the most derived object starts.
volatile
3.11. Overloadable declarations [over.load]
Modify as follows.
Parameter declarations that differ only in the presence or absence of
const and/orare equivalent. That is, the
volatile
const andtypespecifiers for each parameter type are ignored when determining which function is being declared, defined, or called.
volatile
3.12. Builtin operators [over.built]
Modify as follows.
In the remainder of this section, vq represents eitheror no cvqualifier.
volatile For every
pair (T, vq), where T is anarithmetic type T other than, there exist candidate operator functions of the form
bool
vq T & operator ++ ( vq T & ); T operator ++ ( vq T & , int ); For every
pair (T, vq), where T is anarithmetic type T other than, there exist candidate operator functions of the form
bool
vq T & operator  ( vq T & ); T operator  ( vq T & , int ); For every
pair (T, vq)T , where T is a cvqualified or cvunqualified object type, there exist candidate operator functions of the form
T * vq & operator ++ ( T * vq & ); T * vq & operator  ( T * vq & ); T * operator ++ ( T * vq & , int ); T * operator  ( T * vq & , int ); For every quintuple (C1, C2, T, cv1, cv2), where C2 is a class type, C1 is the same type as C2 or is a derived class of C2, and T is an object type or a function type, there exist candidate operator functions of the form
cv12 T & operator >* ( cv1 C1 * , cv2 T C2 ::* ); For every
triplepair (L,vq,R), where L is an arithmetic type, and R is a promoted arithmetic type, there exist candidate operator functions of the form
void operator = ( volatile L & , R ); vq L & operator = ( vq L & , R ); vq L & operator *= ( vq L & , R ); vq L & operator /= ( vq L & , R ); vq L & operator += ( vq L & , R ); vq L & operator = ( vq L & , R ); For
every pair (T, vq), where T is any typeall types T , there exist candidate operator functions of the form
void operator = ( T * volatile & , T * ); T * vq & operator = ( T * vq & , T * ); For every
pair (T, vq), where T is anenumeration or pointer to member type T , there exist candidate operator functions of the form
void operator = ( volatile T & , T ); vq T & operator = ( vq T & , T ); For every
pair (T, vq)T , where T is a cvqualified or cvunqualified object type, there exist candidate operator functions of the form
T * vq & operator += ( T * vq & , std :: ptrdiff_t ); T * vq & operator = ( T * vq & , std :: ptrdiff_t ); For every
triplepair (L,vq,R), where L is an integral type, and R is a promoted integral type, there exist candidate operator functions of the form
vq L & operator %= ( vq L & , R ); vq L & operator <<= ( vq L & , R ); vq L & operator >>= ( vq L & , R ); vq L & operator &= ( vq L & , R ); vq L & operator ^= ( vq L & , R ); vq L & operator = ( vq L & , R );
3.13. Tuples [tuple]
Modify as follows.
Header
synopsis [tuple.syn]:
< tuple >
namespace std { [...] // [ tuple.helper , tuple helper classes template < class T > class tuple_size ; // not defined template < class T > class tuple_size < const T > ; template < class T > class tuple_size < volatile T > ; template < class T > class tuple_size < const volatile T > ; template < class ... Types > class tuple_size < tuple < Types ... >> ; template < size_t I , class T > class tuple_element ; // not defined template < size_t I , class T > class tuple_element < I , const T > ; template < size_t I , class T > class tuple_element < I , volatile T > ; template < size_t I , class T > class tuple_element < I , const volatile T > ; [...] } [...]
Tuple helper classes [tuple.helper]
template < class T > class tuple_size < const T > ; emplate < class T > class tuple_size < volatile T > ; emplate < class T > class tuple_size < const volatile T > ; Let
denote
TS of the cvunqualified type
tuple_size < T > . If the expression
T is wellformed when treated as an unevaluated operand, then each of the three templates shall satisfy the
TS :: value requirements with a base characteristic of
TransformationTrait
integral_constant < size_t , TS :: value > Otherwise, they shall have no member
.
value Access checking is performed as if in a context unrelated to
and
TS . Only the validity of the immediate context of the expression is considered. [ Note: The compilation of the expression can result in side effects such as the instantiation of class template specializations and function template specializations, the generation of implicitlydefined functions, and so on. Such side effects are not in the "immediate context" and can result in the program being illformed. —end note ]
T In addition to being available via inclusion of the
header, the
< tuple > three templates aretemplate is available when any of the headers,
< array > , or
< ranges > are included.
< utility >
template < size_t I , class T > class tuple_element < I , const T > ; template < size_t I , class T > class tuple_element < I , volatile T > ; template < size_t I , class T > class tuple_element < I , const volatile T > ; Let
denote
TE of the cvunqualified type
tuple_element_t < I , T > . Then
T each of the three templatesthe template shall satisfy therequirements with a member typedef
TransformationTrait that names the following type:
type .
add_const_t < TE >
 for the first specialization,
,
add_const_t < TE >  for the second specialization,
, and
add_volatile_t < TE >  for the third specialization,
.
add_cv_t < TE > In addition to being available via inclusion of the
header, the
< tuple > three templates aretemplate is available when any of the headers,
< array > , or
< ranges > are included.
< utility >
3.14. Variants [variant]
Modify as follows.
synopsis [variant.syn]
< variant >
namespace std { // [ variant.variant ], class template variant template < class ... Types > class variant ; // [ variant.helper ], variant helper classes template < class T > struct variant_size ; // not defined template < class T > struct variant_size < const T > ; template < class T > struct variant_size < volatile T > ; template < class T > struct variant_size < const volatile T > ; template < class T > inline constexpr size_t variant_size_v = variant_size < T >:: value ; template < class ... Types > struct variant_size < variant < Types ... >> ; template < size_t I , class T > struct variant_alternative ; // not defined template < size_t I , class T > struct variant_alternative < I , const T > ; template < size_t I , class T > struct variant_alternative < I , volatile T > ; template < size_t I , class T > struct variant_alternative < I , const volatile T > ; [...] }
helper classes [variant.helper]
variant
template < class T > struct variant_size ; Remark: All specializations of
shall satisfy the
variant_size requirements with a base characteristic of
UnaryTypeTrait for some
integral_constant < size_t , N > .
N template < class T > class variant_size < const T > ; template < class T > class variant_size < volatile T > ; template < class T > class variant_size < const volatile T > ; Let
denote
VS of the cvunqualified type
variant_size < T > . Then
T each of the three templatesthe template shall satisfy therequirements with a base characteristic of
UnaryTypeTrait .
integral_constant < size_t , VS :: value >
template < class ... Types > struct variant_size < variant < Types ... >> : integral_constant < size_t , sizeof ...( Types ) > { };
template < size_t I , class T > class variant_alternative < I , const T > ; template < size_t I , class T > class variant_alternative < I , volatile T > ; template < size_t I , class T > class variant_alternative < I , const volatile T > ; Let
denote
VA of the cvunqualified type
variant_alternative < I , T > . Then
T each of the three templatesthe template shall meet therequirements with a member typedef
TransformationTrait that names the following type:
type .
add_const_t < VA :: type >
 for the first specialization,
,
add_const_t < VA :: type >  for the second specialization,
, and
add_volatile_t < VA :: type >  for the third specialization,
.
add_cv_t < VA :: type >
3.15. Atomic operations library [atomics]
Modify as follows.
Operations on atomic types [atomics.types.operations]
[ Note: Many operations are volatilequalified. The "volatile as device register" semantics have not changed in the standard. This qualification means that volatility is preserved when applying these operations to volatile objects. It does not mean that operations on nonvolatile objects become volatile. —end note ]
[...]
bool is_lock_free () const volatile noexcept ; bool is_lock_free () const noexcept ; Returns:
true
if the object’s operations are lockfree,false
otherwise.[ Note: The return value of the
member function is consistent with the value of
is_lock_free for the same type. —end note ]
is_always_lock_free
void store ( T desired , memory_order order = memory_order :: seq_cst ) volatile noexcept ; void store ( T desired , memory_order order = memory_order :: seq_cst ) noexcept ; Requires: The
argument shall not be
order ,
memory_order :: consume , nor
memory_order :: acquire .
memory_order :: acq_rel Effects: Atomically replaces the value pointed to by
Remarks: Thewith the value of
this . Memory is affected according to the value of
desired .
order overload shall only participate in overload resolution when
volatile is
atomic < T >:: is_always : lock_free true
.
T operator = ( T desired ) volatile noexcept ; T operator = ( T desired ) noexcept ; Effects: Equivalent to
.
store ( desired ) Returns:
.
desired
T load ( memory_order order = memory_order :: seq_cst ) const volatile noexcept ; T load ( memory_order order = memory_order :: seq_cst ) const noexcept ; Requires: The
argument shall not be
order nor
memory_order :: release .
memory_order :: acq_rel Effects: Memory is affected according to the value of
.
order Returns: Atomically returns the value pointed to by
Remarks: The.
this overload shall only participate in overload resolution when
volatile is
atomic < T >:: is_always : lock_free true
.
operator T () const volatile noexcept ; operator T () const noexcept ; Effects: Equivalent to:
return load ();
T exchange ( T desired , memory_order order = memory_order :: seq_cst ) volatile noexcept ; T exchange ( T desired , memory_order order = memory_order :: seq_cst ) noexcept ; Effects: Atomically replaces the value pointed to by
with
this . Memory is affected according to the value of
desired . These operations are atomic readmodifywrite operations.
order Returns: Atomically returns the value pointed to by
Remarks: Theimmediately before the effects.
this overload shall only participate in overload resolution when
volatile is
atomic < T >:: is_always : lock_free true
.
bool compare_exchange_weak ( T & expected , T desired , memory_order success , memory_order failure ) volatile noexcept ; bool compare_exchange_weak ( T & expected , T desired , memory_order success , memory_order failure ) noexcept ; bool compare_exchange_strong ( T & expected , T desired , memory_order success , memory_order failure ) volatile noexcept ; bool compare_exchange_strong ( T & expected , T desired , memory_order success , memory_order failure ) noexcept ; bool compare_exchange_weak ( T & expected , T desired , memory_order order = memory_order :: seq_cst ) volatile noexcept ; bool compare_exchange_weak ( T & expected , T desired , memory_order order = memory_order :: seq_cst ) noexcept ; bool compare_exchange_strong ( T & expected , T desired , memory_order order = memory_order :: seq_cst ) volatile noexcept ; bool compare_exchange_strong ( T & expected , T desired , memory_order order = memory_order :: seq_cst ) noexcept ; Requires: The
argument shall not be
failure nor
memory_order :: release .
memory_order :: acq_rel Effects: Retrieves the value in
. It then atomically compares the value representation of the value pointed to by
expected for equality with that previously retrieved from
this ,eand if true, replaces the value pointed to by
expected with that in
this . If and only if the comparison is true, memory is affected according to the value of
desired , and if the comparison is false, memory is affected according to the value of
success . When only one
failure argument is supplied, the value of
memory_order is
success , and the value of
order is
failure except that a value of
order shall be replaced by the value
memory_order :: acq_rel and a value of
memory_order :: acquire shall be replaced by the value
memory_order :: release . If and only if the comparison is false then, after the atomic operation, the value in
memory_order :: relaxed is replaced by the value pointed to by
expected during the atomic comparison. If the operation returns
this true
, these operations are atomic readmodifywrite operations on the memory pointed to by. Otherwise, these operations are atomic load operations on that memory.
this Returns: The result of the comparison.
Remarks: Theoverloads shall only participate in overload resolution when
volatile is
atomic < T >:: is_always : lock_free true
.[...]
Specializations for integers [atomics.types.int]
T fetch_ key ( T operand , memory_order order = memory_order :: seq_cst ) volatile noexcept ; T fetch_ key ( T operand , memory_order order = memory_order :: seq_cst ) noexcept ; Effects: Atomically replaces the value pointed to by
with the result of the computation applied to the value pointed to by
this and the given
this . Memory is affected according to the value of
operand . These operations are atomic readmodifywrite operations.
order Returns: Atomically, the value pointed to by
Remarks: Theimmediately before the effects.
this overloads shall only participate in overload resolution when
volatile is
atomic < T >:: is_always : lock_free true
.Remarks: For signed integer types, the result is as if the object value and parameters were converted to their corresponding unsigned types, the computation performed on those types, and the result converted back to the signed type. [ Note: There are no undefined results arising from the computation. —end note ]
T operator op = ( T operand ) volatile noexcept ; T operator op = ( T operand ) noexcept ; Effects: Equivalent to:
Remarks: The
return fetch_ key ( operand ) op operand ; overloads shall only participate in overload resolution when
volatile is
atomic < T >:: is_always : lock_free true
.Specializations for floatingpoint types [atomics.types.float]
The following operations perform arithmetic addition and subtraction computations. The key, operator, and computation correspondence are identified in [atomic.arithmetic.computations].
T A :: fetch_ key ( T operand , memory_order order = memory_order_seq_cst ) volatile noexcept ; T A :: fetch_ key ( T operand , memory_order order = memory_order_seq_cst ) noexcept ; Effects: Atomically replaces the value pointed to by
with the result of the computation applied to the value pointed to by
this and the given
this . Memory is affected according to the value of
operand . These operations are atomic readmodifywrite operations.
order Returns: Atomically, the value pointed to by
Remarks: Theimmediately before the effects.
this overloads shall only participate in overload resolution when
volatile is
atomic < T >:: is_always : lock_free true
.Remarks: If the result is not a representable value for its type the result is unspecified, but the operations otherwise have no undefined behavior. Atomic arithmetic operations on
should conform to the
floating  point traits associated with the floatingpoint type. The floatingpoint environment for atomic arithmetic operations on
std :: numeric_limits < floating  point > may be different than the calling thread’s floatingpoint environment.
floating  point
T operator op = ( T operand ) volatile noexcept ; T operator op = ( T operand ) noexcept ; Effects: Equivalent to:
return fetch_ key ( operand ) op operand ; Remarks: If the result is not a representable value for its type the result is unspecified, but the operations otherwise have no undefined behavior. Atomic arithmetic operations on
should conform to the
floating  point traits associated with the floatingpoint type. The floatingpoint environment for atomic arithmetic operations on
std :: numeric_limits < floating  point > may be different than the calling thread’s floatingpoint environment.
floating  point Partial specialization for pointers [atomics.types.pointer]
T * fetch_ key ( ptrdiff_t operand , memory_order order = memory_order :: seq_cst ) volatile noexcept ; T * fetch_ key ( ptrdiff_t operand , memory_order order = memory_order :: seq_cst ) noexcept ; Requires: T shall be an object type, otherwise the program is illformed. [ Note: Pointer arithmetic on \tcode{void} or function pointers is illformed. —end note* ]
Effects: Atomically replaces the value pointed to by
with the result of the computation applied to the value pointed to by
this and the given
this . Memory is affected according to the value of
operand . These operations are atomic readmodifywrite operations.
order Returns: Atomically, the value pointed to by
Remarks: Theimmediately before the effects.
this overloads shall only participate in overload resolution when
volatile is
atomic < T >:: is_always : lock_free true
.Remarks: The result may be an undefined address, but the operations otherwise have no undefined behavior.
T * operator op = ( ptrdiff_t operand ) volatile noexcept ; T * operator op = ( ptrdiff_t operand ) noexcept ; Effects: Equivalent to:
return fetch_ key ( operand ) op operand ; Member operators common to integers and pointers to objects [atomics.types.memop]
T operator ++ ( int ) volatile noexcept ; T operator ++ ( int ) noexcept ; Effects: Equivalent to:
return fetch_add ( 1 );
T operator  ( int ) volatile noexcept ; T operator  ( int ) noexcept ; Effects: Equivalent to:
return fetch_sub ( 1 );
T operator ++ () volatile noexcept ; T operator ++ () noexcept ; Effects: Equivalent to:
return fetch_add ( 1 ) + 1 ;
T operator  () volatile noexcept ; T operator  () noexcept ; Effects: Equivalent to:
return fetch_sub ( 1 )  1 ; Nonmember functions [atomics.nonmembers]
A nonmember function template whose name matches the pattern
or the pattern
atomic_ f invokes the member function
atomic_ f _explicit , with the value of the first parameter as the object expression and the values of the remaining parameters (if any) as the arguments of the member function call, in order. An argument for a parameter of type
f is dereferenced when passed to the member function call. If no such member function exists, the program is illformed.
atomic < T >:: value_type *
template < class T > void atomic_init ( volatile atomic < T >* object , typename atomic < T >:: value_type desired ) noexcept ; template < class T > void atomic_init ( atomic < T >* object , typename atomic < T >:: value_type desired ) noexcept ; Effects: Nonatomically initializes
Remarks: Thewith value
* object . This function shall only be applied to objects that have been default constructed, and then only once. [ Note: These semantics ensure compatibility with C. —end note ] [ Note: Concurrent access from another thread, even via an atomic operation, constitutes a data race. —end note ]
desired overloads shall only participate in overload resolution when
volatile is
atomic < T >:: is_always : lock_free true
.[ Note: The nonmember functions enable programmers to write code that can be compiled as either C or C++, for example in a shared header file. —end note ]
3.16. Annex D
All deletions above should be added to Annex D, such that
is now
deprecated in these use cases.