Movatterモバイル変換

[Moved to DR at the April, 2013 meeting.]

Notes from the June, 2016 meeting:

The resolution ofissue 2094 revertthe changes above revert the changes ofvolatilequalification on trivial copyability.

Proposed resolution, October, 2012:

1. Change 6.9 [basic.types] paragraph 9 as follows:

...Scalar types, trivially copyable class types (Clause 11 [class]), arrays of such types, andcv-qualifiednon-volatile const-qualified versions of these types(6.9.5 [basic.type.qualifier]) are collectively calledtriviallycopyable types. Scalar types, trivial class types...

2. Change 9.2.9.2 [dcl.type.cv] paragraphs 6-7 as follows:

What constitutes an access to an object that hasvolatile-qualified type is implementation-defined. If an attemptis made to refer to an object defined with a volatile-qualified typethrough the use of a glvalue with a non-volatile-qualified type, theprogram behavior is undefined.

[Note:volatile is a hint to the implementation toavoid aggressive optimization involving the object because the valueof the object might be changed by means undetectable by animplementation.Furthermore, for some implementations,volatile might indicate that special hardware instructionsare required to access the object. See 6.10.1 [intro.execution]for detailed semantics. In general, the semantics ofvolatile are intended to be the same in C++ as they are inC. —end note]

3. Change 11.4.5.3 [class.copy.ctor] paragraph 12 as follows:

A copy/move constructor for classX is trivial if it is notuser-provided, its declared parameter type is the same as if it hadbeen implicitly declared, and if

• classX has no virtual functions (11.7.3 [class.virtual]) and no virtual base classes (11.7.2 [class.mi]),and

• classX has no non-static data members ofvolatile-qualified type, and

• ...

4. Change 11.4.5.3 [class.copy.ctor] paragraph 25 as follows:

A copy/move assignment operator for classX is trivial ifit is not user-provided, its declared parameter type is the same as ifit had been implicitly declared, and if

• classX has no virtual functions (11.7.3 [class.virtual]) and no virtual base classes (11.7.2 [class.mi]),and

• classX has no non-static data members ofvolatile-qualified type, and

• ...

Notes from the April, 2005 meeting:

It is not clear whether the volatile qualifier actually guaranteesatomicity in this way. Also, the work on the memory model formultithreading being done by the Evolution Working Group seems at thispoint likely to specify additional semantics for volatile data, andthat work would need to be considered before resolving this issue.

(See alsoissue 1746.)

In 6.9 [basic.types] paragraph 10, the standard makesit quite clear that volatile qualified types are PODs:

Arithmetic types (6.9.2 [basic.fundamental]), enumerationtypes, pointer types, and pointer to member types (6.9.4 [basic.compound]), andcv-qualified versions of thesetypes (6.9.5 [basic.type.qualifier]) are collectively calledscalar types. Scalar types, POD-struct types, POD-uniontypes (Clause 11 [class]), arrays of such types andcv-qualified versions of these types (6.9.5 [basic.type.qualifier]) are collectively calledPOD types.

However in 6.9 [basic.types] paragraph 3, thestandard makes it clear that PODs can be copied “asif” they were a collection of bytes bymemcpy:

For any POD typeT, if two pointers toT point todistinctT objectsobj1 andobj2, whereneitherobj1 norobj2 is a base-class subobject, ifthe value ofobj1 is copied intoobj2, usingthestd::memcpy library function,obj2 shallsubsequently hold the same value asobj1.

The problem with this is that a volatile qualified type mayneed to be copied in a specific way (by copying using only atomicoperations on multithreaded platforms, for example) in order toavoid the “memory tearing” that may occur with abyte-by-byte copy.

I realise that the standard says very little about volatilequalified types, and nothing at all (yet) about multithreadedplatforms, but nonetheless this is a real issue, for thefollowing reason:

The forthcoming TR1 will define a series of traits thatprovide information about the properties of a type, includingwhether a type is a POD and/or has trivial construct/copy/assignoperations. Libraries can use this information to optimise theircode as appropriate, for example an array of typeTmight be copied with amemcpy rather than anelement-by-element copy ifT is a POD. This was one ofthe main motivations behind the type traits chapter of the TR1.However it's not clear how volatile types (or POD's which have avolatile type as a member) should be handled in these cases.