is_trivially_destructible replaced has_trivial_destructor

C++11 中的 type_traits, 改变了一些约定成俗的名字:

我们经常使用的 has_trivial_destructor, 变成了 is_trivially_destructible, 现在已有不少编译器实现了 has_trivial_destructor, (std, std::tr1). 如此, 要写可移植的代码, 要么使用 tr1, 要么使用 boost, 鉴于 tr1 出现的比 boost 更晚, boost 一般是首选, 而新的编译器往往自带了 tr1, 而 boost 要另外安装………

We think in general, but we live in details. 一个简单的 type_traits, 也需要这么多折腾.

以下是标准关于 type_traits 更新的详细列表

 

 

 

Summary of renamed traits
General form Nothrow form Trivial form
Construction is_constructible is_nothrow_constructible
hasis_default_constructibleor hasis_nothrow_default_constructibleor hasis_trivially_default_constructibleor
hasis_copy_constructibleor hasis_nothrow_copy_constructibleor hasis_trivially_copy_constructibleor
hasis_move_constructibleor hasis_nothrow_move_constructibleor hasis_trivially_move_constructibleor
Destruction hasis_trivially_destructibleor
Assignment hasis_copy_assignable hasis_nothrow_copy_assignable hasis_trivially_copy_assignable
hasis_move_assignable hasis_nothrow_move_assignable hasis_trivially_move_assignable

 

Furthermore, as noted in GB 92 for the “nothrow” traits, the definitions have become redundant and confusing. This redundancy and confusion actually extends to nearly all of these traits, and in some cases actually leads to incorrect
definitions, or at the very least, a lack of self-consistency among the traits. For example, as specified in the current Working Draft:

With our proposed clarifying names, we wish for is_copy_constructible<T> to have the exact same behavior as is_constructible<T, const T&>. So we have adjusted the definitions of the is_*_constructible traits
to be simple synonyms for is_constructible and similarly for the “nothrow” variants. E.g.:

template <class T> structhas_nothrow_copy_constructoris_nothrow_copy_constructible; has_trivial_copy_constructor<T>::value is true oris_nothrow_constructible<U, const U&>::value is true, where U isremove_all_extents<T>::type.
is_nothrow_constructible<T, const T&>::value is true.
T shall be a complete type, (possibly cv-qualified) void, or an array of unknown bound.

This formulation makes it much easier to get the definitions correct. I.e. what it means to be “nothrow constructible” is defined in exactly one place (the definition ofis_nothrow_constructible). The other “nothrow constructible”
traits reuse this definition as much as possible, with no repetition.

However we note that we can not currently apply this formula to the “trivially constructible” traits, nor to is_trivially_destructible, nor to any of the assignable traits. The problem is the lack of is_destructible (FI
18), lack of is_trivially_constructible, and the lack of generalized assignable traits. We strongly feel that this lack of completeness will inevitably lead to situations where programmers will not be able to query or assert properties of types necessary
to the correct operation of their code. For example a container is likely to assert that a contained type have a non-throwing destructor. Lack of this property leads to the container’s destructor becoming a source of memory leaks.

Therefore we propose the following 6 new traits to complete the suite of traits:

 

Summary of traits, new traits shown as insertions
General form Nothrow form Trivial form
Construction is_constructible is_nothrow_constructible is_trivially_constructible
is_default_constructible is_nothrow_default_constructible is_trivially_default_constructible
is_copy_constructible is_nothrow_copy_constructible is_trivially_copy_constructible
is_move_constructible is_nothrow_move_constructible is_trivially_move_constructible
Destruction is_destructible is_nothrow_destructible is_trivially_destructible
Assignment is_assignable is_nothrow_assignable is_trivially_assignable
is_copy_assignable is_nothrow_copy_assignable is_trivially_copy_assignable
is_move_assignable is_nothrow_move_assignable is_trivially_move_assignable

 

We address GB 91 in the definition of the newly introduced is_assignable trait, using declval as suggested. All of the rest of the assignable traits reuse this definition without repetition.

In addition we wish to address GB 50 and GB 51 in this paper because the topic is intimately related to the definition of move construction and move assignment and subsequently theis_move_constructible and is_move_assignable traits.

The following list shows the current usages of the terms “move-construct” and “move-assign” in the library. While some occurrences are purely descriptive usages of these words, most of them refer to what the type traits is_move_constructible<T> and is_move_assignable<T> stand
for. The list omits to enumerate all usages of these terms within the definition of pair and tuples, because those will be completely replaced by another paper (N3140).

  1. Table 42, entry: X::propagate_on_container_move_assignment

    true_type only if an allocator of type X should be moved when the client container is move-assigned.

  2. 20.8.14.2.1/8: “otherwise, move-constructs the target”
  3. 20.9.10.2.1/14: “This unique_ptr will hold a value move constructed from d.”
  4. 20.9.10.2.1/19: “If D is a reference type, this deleter is copy constructed from u‘s deleter; otherwise, this deleter is move constructed from u‘s deleter.”
  5. 20.9.10.2.1/24: “If E is a reference type, this deleter is copy constructed from u‘s deleter; otherwise, this deleter is move constructed from u‘s deleter.”
  6. 20.9.11.2.1/24: “Effects: Move-constructs a shared_ptr instance from r.”
  7. Table 93 — Container requirements, entry “a = rv“: “All existing elements of a are either move assigned to or destroyed”
  8. Table 96 — Allocator-aware container requirements (continued), entry “X(rv) X u(rv)“: “Requires: move construction of A shall not exit via an exception.”
  9. Table 96 — Allocator-aware container requirements (continued), entry “a = rv“:

    All existing elements of a are either move assigned to or destroyed.

  10. 23.5.2.1/2: “Effects: Initializes comp with x and c with y (copy constructing or move constructing as appropriate);”
  11. 23.5.2.1/4: “Effects: Initializes comp with x and c with y (copy constructing or move constructing as appropriate);”
  12. 26.7.4/before p.1: “assigns the result to *(result + (i - first)), and move assigns from val to acc.”
  13. 27.7.1.1.1/3: “Effects: Move constructs from the rvalue rhs. This is accomplished by [..]” (Defined)
  14. 27.7.1.5.1/3: “Effects: Move constructs from the rvalue rhs by constructing the basic_istream base class with move(rhs).” (Defined)
  15. 27.7.2.2/5: “Effects: Move constructs from the rvalue rhs. This is accomplished by [..]” (Defined)
  16. 27.8.1.1/4: “Effects: Move constructs from the rvalue rhs. [..]” (Defined)
  17. 27.8.1.2/1: “Effects: After the move assignment [..]” (Descriptive)
  18. 27.8.2.1/3 “Move constructs from the rvalue rhs. This is accomplished by move constructing the base class, and the contained basic_stringbuf. [..]”
  19. 27.8.3.2/1 “Effects: Move assigns the base and members of *this from the base and corresponding members of rhs.”
  20. 27.8.5/3: “Move constructs from the rvalue rhs. This is accomplished by move constructing the base class, and the contained basic_stringbuf. [..]”
  21. 27.8.5.1/1: “Effects: Move assigns the base and members of *this from the base and corresponding members of rhs.”
  22. 27.9.1.2/3: “Effects: Move constructs from the rvalue rhs.” (Descriptive)
  23. 27.9.1.3/1: “Effects: Calls this->close() then move assigns from rhs.” (Descriptive)
  24. 27.9.1.7/4: “Effects: Move constructs from the rvalue rhs. This is accomplished by move constructing the base class, and the contained basic_filebuf. [..]”
  25. 27.9.1.8/1: “Effects: Move assigns the base and members of *this from the base and corresponding members of rhs.” (Descriptive)
  26. 27.9.1.11/4: “Effects: Move constructs from the rvalue rhs. This is accomplished by move constructing the base class, and the contained basic_filebuf. [..]”
  27. 27.9.1.12/1 “Effects: Move assigns the base and members of *this from the base and corresponding members of rhs.”
  28. 27.9.1.15/4: “Effects: Move constructs from the rvalue rhs. This is accomplished by move constructing the base class, and the contained basic_filebuf. [..]”
  29. 27.9.1.16/1: “Effects: Move assigns the base and members of *this from the base and corresponding members of rhs.”
  30. 28.8.2/12: “Effects: Move constructs an object of class basic_regex from e.” (Descriptive)
  31. 28.8.3/9: “Effects: move assigns from that into *this and returns *this.” (Descriptive)
  32. 28.10.1/5: “Effects: Move-constructs an object of class match_results from m satisfying the same postconditions as Table 138.” (Descriptive) “Additionally, the storedAllocator value is move constructed
    from m.get_allocator().” (Defined meaning)
  33. 28.10.1/8: “Effects: Move-assigns m to *this. The postconditions of this function are indicated in Table 138.” (Descriptive)
  34. 30.6.6/7: “Effects: move constructs a future object that refers to the associated asynchronous state that was originally referred to by rhs (if any).” (Descriptive)
  35. 30.6.7/10: “Effects: move constructs a shared_future object that refers to the associated asynchronous state that was

 

作者:
该日志由 csdn-whinah 于2011年09月29日发表在C++分类下, 你可以发表评论,并在保留原文地址及作者的情况下引用到你的网站或博客。
转载请注明: is_trivially_destructible replaced has_trivial_destructor
标签:
【上一篇】
【下一篇】

您可能感兴趣的文章:

发表评论

您必须 登录 后才能发表评论。