feedc0de/boost_type_traits
1
0
Fork 0
forked from boostorg/type_traits
Code Pull Requests Activity

Bring more docs up to date.

Browse Source
This commit is contained in:
jzmaddock
2015-06-11 09:57:56 +01:00
parent c0ca135b78
commit 1dfcdd7bb2
6 changed files with 30 additions and 34 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
doc/has_trivial_assign.qbk
View File

@@ -16,13 +16,12 @@ If a type has a trivial assignment-operator then the operator has the same effec
as copying the bits of one object to the other:
calls to the operator can be safely replaced with a call to `memcpy`.
__compat If the compiler does not support partial-specialization of class
templates, then this template can not be used with function types.
Without some (as yet unspecified) help from the compiler,
__compat Without some (as yet unspecified) help from the compiler,
has_trivial_assign will never report that a user-defined class or struct has a
trivial constructor; this is always safe, if possibly sub-optimal.
Currently (May 2011) compilers more recent than Visual C++ 8, GCC-4.3, Greenhills 6.0,
trivial constructor; this is always safe, if possibly sub-optimal. In order to
correctly handle deleted or private assignment operators, the compiler must also
support C++11's `decltype`.
Currently (May 2015) compilers more recent than Visual C++ 8, GCC-4.3, Greenhills 6.0,
Intel-11.0, and Codegear have the necessary compiler __intrinsics to ensure that this
trait "just works". You may also test to see if the necessary __intrinsics are available
by checking to see if the macro `BOOST_HAS_TRIVIAL_ASSIGN` is defined.

9
doc/has_trivial_constructor.qbk
View File

@@ -24,13 +24,12 @@ to omit a call to a single trivial-constructor call is of no benefit whatsoever.
However, if loops and/or exception handling code can also be omitted, then some
benefit in terms of code size and speed can be obtained.
__compat If the compiler does not support partial-specialization of class
templates, then this template can not be used with function types.
Without some (as yet unspecified) help from the compiler,
__compat Without some (as yet unspecified) help from the compiler,
has_trivial_constructor will never report that a user-defined class or struct has a
trivial constructor; this is always safe, if possibly sub-optimal.
Currently (May 2011) compilers more recent than Visual C++ 8, GCC-4.3, Greenhills 6.0,
In addition, in order to correctly handle private or deleted default-constructors then
C++11's `deltype` is required.
Currently (May 2015) compilers more recent than Visual C++ 8, GCC-4.3, Greenhills 6.0,
Intel-11.0, and Codegear have the necessary compiler __intrinsics to ensure that this
trait "just works". You may also test to see if the necessary __intrinsics are available
by checking to see if the macro `BOOST_HAS_TRIVIAL_CONSTRUCTOR` is defined.

9
doc/has_trivial_copy.qbk
View File

@@ -22,13 +22,12 @@ If a type has a trivial copy-constructor then the constructor has the same effec
as copying the bits of one object to the other:
calls to the constructor can be safely replaced with a call to `memcpy`.
__compat If the compiler does not support partial-specialization of class
templates, then this template can not be used with function types.
Without some (as yet unspecified) help from the compiler,
__compat Without some (as yet unspecified) help from the compiler,
has_trivial_copy will never report that a user-defined class or struct has a
trivial constructor; this is always safe, if possibly sub-optimal.
Currently (May 2011) compilers more recent than Visual C++ 8, GCC-4.3, Greenhills 6.0,
In addition, in order to correctly handle deleted or private copy-constructors
then C++11's `dectype` is required.
Currently (May 2015) compilers more recent than Visual C++ 8, GCC-4.3, Greenhills 6.0,
Intel-11.0, and Codegear have the necessary compiler __intrinsics to ensure that this
trait "just works". You may also test to see if the necessary __intrinsics are available
by checking to see if the macro `BOOST_HAS_TRIVIAL_COPY` is defined.

9
doc/has_trivial_destructor.qbk
View File

@@ -18,13 +18,12 @@ to omit a call to a single trivial-constructor call is of no benefit whatsoever.
However, if loops and/or exception handling code can also be omitted, then some
benefit in terms of code size and speed can be obtained.
__compat If the compiler does not support partial-specialization of class
templates, then this template can not be used with function types.
Without some (as yet unspecified) help from the compiler,
__compat Without some (as yet unspecified) help from the compiler,
has_trivial_destructor will never report that a user-defined class or struct has a
trivial destructor; this is always safe, if possibly sub-optimal.
Currently (May 2011) compilers more recent than Visual C++ 8, GCC-4.3, Greenhills 6.0,
In addition, in order to correctly handle deleted or private destructors then
support for C++11's `decltype` is required.
Currently (June 2015) compilers more recent than Visual C++ 8, GCC-4.3, Greenhills 6.0,
Intel-11.0, and Codegear have the necessary compiler __intrinsics to ensure that this
trait "just works". You may also test to see if the necessary __intrinsics are available
by checking to see if the macro `BOOST_HAS_TRIVIAL_DESTRUCTOR` is defined.

14
doc/has_trivial_move_assign.qbk
View File

@@ -17,14 +17,14 @@ If a type has a trivial move assignment-operator then the operator has the same
as copying the bits of one object to the other:
calls to the operator can be safely replaced with a call to `memcpy`.
__compat If the compiler does not support partial-specialization of class
templates, then this template can not be used with function types.
Without some (as yet unspecified) help from the compiler,
__compat Without some (as yet unspecified) help from the compiler,
has_trivial_move_assign will never report that a user-defined class or struct has a
trivial constructor; this is always safe, if possibly sub-optimal.
Currently (February 2013) compilers have no necessary __intrinsics to ensure that this
trait "just works". You may also test to see if the necessary __intrinsics are available
trivial move assign; this is always safe, if possibly sub-optimal.
In addition, in order to correctly handle private or deleted move assignment
operators then c++11's `decltype` is required.
Currently (June 2015) compilers that have the necessary __intrinsics to ensure that this
trait "just works" include Clang, GCC-5.1 and MSVC-12.0.
You may also test to see if the necessary __intrinsics are available
by checking to see if the macro `BOOST_HAS_TRIVIAL_MOVE_ASSIGN` is defined.

12
doc/has_trivial_move_constructor.qbk
View File

@@ -18,14 +18,14 @@ If a type has a trivial move-constructor then the constructor has the same effec
as copying the bits of one object to the other:
calls to the constructor can be safely replaced with a call to `memcpy`.
__compat If the compiler does not support partial-specialization of class
templates, then this template can not be used with function types.
Without some (as yet unspecified) help from the compiler,
__compat Without some (as yet unspecified) help from the compiler,
has_trivial_move_constructor will never report that a user-defined class or struct has a
trivial constructor; this is always safe, if possibly sub-optimal.
Currently (February 2013) compilers have no necessary __intrinsics to ensure that this
trait "just works". You may also test to see if the necessary __intrinsics are available
In addition C++11's `decltype` is required to correctly support deleted or private
move constructors.
Currently (June 2015) compilers that have the necessary __intrinsics to ensure that this
trait "just works" include Clang, GCC-5.1, and MSVC-12.0.
You may also test to see if the necessary __intrinsics are available
by checking to see if the macro `BOOST_HAS_TRIVIAL_MOVE_CONSTRUCTOR` is defined.