c++ - std::is_trivially_copyable - 为什么 volatile 标量类型不能轻易复制？

Question

C++17 的当前标准(我观察到 C++11 的类似措辞)对于可复制的类型的措辞非常困惑。我首先通过以下代码(GCC 5.3.0)偶然发现了这个问题:

class TrivialClass {};
std::is_trivially_copyable<int volatile>::value; // 0
std::is_trivially_copyable<TrivialClass volatile>::value; // 1 ??

让困惑变得更糟，我试图查看 std::is_trivial 对此事的看法，但结果更加困惑。

class TrivialClass {};
std::is_trivial<int volatile>::value; // 1 ??
std::is_trivial<TrivialClass volatile>::value; // 1

很困惑，我检查了最新的 C++17 草案，看看是否有问题，我发现了一些有点模棱两可的措辞，这可能是罪魁祸首:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4567.pdf#page.73

cv-unqualified scalar types, trivially copyable class types (Clause 9), arrays of such types, and non-volatile const-qualified versions of these types (3.9.3) are collectively called trivially copyable types.

这里是关于可简单复制的类的信息:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4567.pdf#page.226

A trivially copyable class is a class that:

— (6.1) has no non-trivial copy constructors (12.8),

— (6.2) has no non-trivial move constructors (12.8),

— (6.3) has no non-trivial copy assignment operators (13.5.3, 12.8),

— (6.4) has no non-trivial move assignment operators (13.5.3, 12.8), and

— (6.5) has a trivial destructor (12.4).

http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4567.pdf#section.12.8

构造函数:

A copy/move constructor for class X is trivial if it is not user-provided, its parameter-type-list is equivalent to the parameter-type-list of an implicit declaration, and if

— (12.1) class X has no virtual functions (10.3) and no virtual base classes (10.1), and

— (12.2) class X has no non-static data members of volatile-qualified type, and

— (12.3) the constructor selected to copy/move each direct base class subobject is trivial, and

— (12.4) for each non-static data member of X that is of class type (or array thereof), the constructor selected to copy/move that member is trivial;

otherwise the copy/move constructor is non-trivial.

作业:

A copy/move assignment operator for class X is trivial if it is not user-provided, its parameter-type-list is equivalent to the parameter-type-list of an implicit declaration, and if

— (25.1) class X has no virtual functions (10.3) and no virtual base classes (10.1), and

— (25.2) class X has no non-static data members of volatile-qualified type, and

— (25.3) the assignment operator selected to copy/move each direct base class subobject is trivial, and

— (25.4) for each non-static data member of X that is of class type (or array thereof), the assignment operator selected to copy/move that member is trivial;

otherwise the copy/move assignment operator is non-trivial.

注意:更新了本节以提供更多信息。我现在认为这是 GCC 中的一个错误。然而，仅此一项并不能回答我所有的问题。

我可以看到这可能是因为 TrivialClass 没有非静态成员，因为它会通过上述规则，所以我添加了一个 int，它仍然以可简单复制的形式返回。

class TrivialClass { int foo; };
std::is_trivially_copyable<int volatile>::value; // 0
std::is_trivially_copyable<TrivialClass volatile>::value; // 1 ??

标准规定 volatile 应由 volatile 对象的子对象继承。这意味着 TrivialClass volatile 的非静态数据成员 foo 现在应该是 int volatile 类型。

http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4567.pdf#page.76

A volatile object is an object of type volatile T, a subobject of such an object, or a mutable subobject of a const volatile object

我们可以通过以下方式确认这在 GCC 中有效:

std::is_same<decltype(((TrivialClass volatile*)nullptr)->foo), int volatile>::value; // 1! (Expected)

困惑，然后我向 int foo 本身添加了一个 volatile。它仍然通过，这显然是一个错误!

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68905#c1

class TrivialClass { int volatile foo; };
std::is_trivially_copyable<int volatile>::value; // 0
std::is_trivially_copyable<TrivialClass volatile>::value; // 1 ??

继续前进，我们看到 std::is_trivial 也按预期工作:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4567.pdf#page.73

Scalar types, trivial class types (Clause 9), arrays of such types and cv-qualified versions of these types (3.9.3) are collectively called trivial types.

好的，我这里有很多问题。

• 为什么 volatile 对 is_trivially_copyable 而不是 is_trivial 很重要？
• is_trivially_copyable 和对象类型有什么关系，是标准的错误还是问题？
• 如果某些东西是易变的，为什么这很重要？

谁能帮我解决这个问题，我真的很茫然。

Answer 1

显然这是修复标准中的缺陷的方式，但你不是唯一对此感到困惑的人。

来自 https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2094 :

2094. Trivial copy/move constructor for class with volatile member

Section: 12.8 [class.copy] Status: open Submitter: Daveed Vandevoorde Date: 2015-03-06

The resolution of issue 496 includedthe addition of 12.8 [class.copy] paragraph 25.2, making a class'scopy/move constructor non-trivial if it has a non-static data memberof volatile-qualified type. This change breaks the IA-64 ABI, so ithas been requested that CWG reconsider this aspect of the resolution.

On a related note, the resolution of issue 496 also changed 3.9[basic.types] paragraph 9, which makes volatile-qualified scalar types“trivial” but not “trivially copyable.” It is not clear why there is adistinction made here; the only actual use of “trivial type” in theStandard appears to be in the description of qsort, which shouldprobably use “trivially copyable.” (See also issue 1746.)

来自问题描述(从 30.12.2004 开始):

496. Is a volatile-qualified type really a POD? :

However in 3.9 [basic.types] paragraph 3, the standard makes it clearthat PODs can be copied “as if” they were a collection of bytes bymemcpy:

For any POD type T, if two pointers to T point to distinct T objectsobj1 and obj2, where neither obj1 nor obj2 is a base-class subobject,if the value of obj1 is copied into obj2, using the std::memcpylibrary function, obj2 shall subsequently hold the same value as obj1.The problem with this is that a volatile qualified type may need to becopied in a specific way (by copying using only atomic operations onmultithreaded platforms, for example) in order to avoid the “memorytearing” that may occur with a byte-by-byte copy.

I realise that the standard says very little about volatile qualifiedtypes, and nothing at all (yet) about multithreaded platforms, butnonetheless this is a real issue, for the following reason:

The forthcoming TR1 will define a series of traits that provide information about the properties of a type, including whether a type is a POD and/or has trivial construct/copy/assign operations. Libraries can use this information to optimise their code as appropriate, for example an array of type T might be copied with a memcpy rather than an element-by-element copy if T is a POD. This was one of the main motivations behind the type traits chapter of the TR1. However it's not clear how volatile types (or POD's which have a volatile type as a member) should be handled in these cases.Notes from the April, 2005 meeting:

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