diff --git a/doc/has_complement.qbk b/doc/has_complement.qbk
index f6b567b..e63b226 100644
--- a/doc/has_complement.qbk
+++ b/doc/has_complement.qbk
@@ -105,5 +105,7 @@ int main() {
* `volatile` qualifier is not properly handled and would lead to undefined behavior
+[prefix_operator_known_issues has_complement..~]
+
[endsect]
diff --git a/doc/has_post_decrement.qbk b/doc/has_post_decrement.qbk
index 2b76d3f..fb07ae4 100644
--- a/doc/has_post_decrement.qbk
+++ b/doc/has_post_decrement.qbk
@@ -106,5 +106,7 @@ int main() {
* `volatile` qualifier is not properly handled and would lead to undefined behavior
+[prefix_operator_known_issues has_post_decrement..--]
+
[endsect]
diff --git a/doc/has_post_increment.qbk b/doc/has_post_increment.qbk
index 06121ec..c35074e 100644
--- a/doc/has_post_increment.qbk
+++ b/doc/has_post_increment.qbk
@@ -106,5 +106,7 @@ int main() {
* `volatile` qualifier is not properly handled and would lead to undefined behavior
+[prefix_operator_known_issues has_post_increment..++]
+
[endsect]
diff --git a/doc/has_pre_decrement.qbk b/doc/has_pre_decrement.qbk
index b239388..de41e44 100644
--- a/doc/has_pre_decrement.qbk
+++ b/doc/has_pre_decrement.qbk
@@ -1,4 +1,4 @@
-[/
+#[/
(C) Copyright 2009-2011 Frederic Bron.
Distributed under the Boost Software License, Version 1.0.
(See accompanying file LICENSE_1_0.txt or copy at
@@ -106,5 +106,7 @@ int main() {
* `volatile` qualifier is not properly handled and would lead to undefined behavior
+[prefix_operator_known_issues has_pre_decrement..--]
+
[endsect]
diff --git a/doc/has_pre_increment.qbk b/doc/has_pre_increment.qbk
index 4008692..4d98429 100644
--- a/doc/has_pre_increment.qbk
+++ b/doc/has_pre_increment.qbk
@@ -106,5 +106,7 @@ int main() {
* `volatile` qualifier is not properly handled and would lead to undefined behavior
+[prefix_operator_known_issues has_pre_increment..++]
+
[endsect]
diff --git a/doc/has_unary_minus.qbk b/doc/has_unary_minus.qbk
index 9ba7988..ecf5fe5 100644
--- a/doc/has_unary_minus.qbk
+++ b/doc/has_unary_minus.qbk
@@ -104,5 +104,7 @@ int main() {
* `volatile` qualifier is not properly handled and would lead to undefined behavior
+[prefix_operator_known_issues has_unary_minus..-]
+
[endsect]
diff --git a/doc/has_unary_plus.qbk b/doc/has_unary_plus.qbk
index 6540164..55eadc9 100644
--- a/doc/has_unary_plus.qbk
+++ b/doc/has_unary_plus.qbk
@@ -104,5 +104,7 @@ int main() {
* `volatile` qualifier is not properly handled and would lead to undefined behavior
+[prefix_operator_known_issues has_unary_plus..+]
+
[endsect]
diff --git a/doc/html/boost_typetraits/reference.html b/doc/html/boost_typetraits/reference.html
index 92587db..d8e7690 100644
--- a/doc/html/boost_typetraits/reference.html
+++ b/doc/html/boost_typetraits/reference.html
@@ -168,6 +168,7 @@
type_identity
type_with_alignment
+
|
diff --git a/doc/html/boost_typetraits/reference/has_complement.html b/doc/html/boost_typetraits/reference/has_complement.html
index 0b05503..e42477e 100644
--- a/doc/html/boost_typetraits/reference/has_complement.html
+++ b/doc/html/boost_typetraits/reference/has_complement.html
@@ -176,6 +176,44 @@
properly handled and would lead to undefined behavior
+
+ Known issues:
+
+
+ For modern compilers (those that support arbitrary SFINAE-expressions and
+ decltype/declval) this trait offers near perfect detection. In this situation
+ the macro BOOST_TT_HAS_ACCURATE_BINARY_OPERATOR_DETECTION
+ will be defined after including <boost/type_traits/has_complement.hpp>
.
+ Please note however, that detection is based on function signature only,
+ in the case that the operator is a function template then has_complement
+ cannot perform introspection of the template function body to ensure that
+ the type meets all of the conceptual requirements of the actual code.
+
+
+ For older compilers (BOOST_TT_HAS_ACCURATE_BINARY_OPERATOR_DETECTION
+ not defined) then there are a number of issues:
+
+
+-
+ This trait cannot detect whether unary
operator
~
+ is public or not: if operator
~
+ is defined as a private class member of type T then instantiating has_complement<T>
+ will produce a compiler error. For this reason has_complement
+ cannot be used to determine whether a type has a public operator
~ or not.
+
+-
+
volatile
qualifier is not
+ properly handled and would lead to undefined behavior
+
+-
+ Capturless lambdas are not supported and will lead to a compiler error
+ if has_complement is instantiated on the lambda type.
+
+-
+ Scoped enum types are not supported and will lead to a compiler error
+ if has_complement is instantiated on such a type.
+
+
|
diff --git a/doc/html/boost_typetraits/reference/has_post_decrement.html b/doc/html/boost_typetraits/reference/has_post_decrement.html
index f73b67e..e2be84c 100644
--- a/doc/html/boost_typetraits/reference/has_post_decrement.html
+++ b/doc/html/boost_typetraits/reference/has_post_decrement.html
@@ -182,6 +182,44 @@
properly handled and would lead to undefined behavior
+
+ Known issues:
+
+
+ For modern compilers (those that support arbitrary SFINAE-expressions and
+ decltype/declval) this trait offers near perfect detection. In this situation
+ the macro BOOST_TT_HAS_ACCURATE_BINARY_OPERATOR_DETECTION
+ will be defined after including <boost/type_traits/has_post_decrement.hpp>
.
+ Please note however, that detection is based on function signature only,
+ in the case that the operator is a function template then has_post_decrement
+ cannot perform introspection of the template function body to ensure that
+ the type meets all of the conceptual requirements of the actual code.
+
+
+ For older compilers (BOOST_TT_HAS_ACCURATE_BINARY_OPERATOR_DETECTION
+ not defined) then there are a number of issues:
+
+
+-
+ This trait cannot detect whether unary
operator
--
+ is public or not: if operator
--
+ is defined as a private class member of type T then instantiating has_post_decrement<T>
+ will produce a compiler error. For this reason has_post_decrement
+ cannot be used to determine whether a type has a public operator
-- or not.
+
+-
+
volatile
qualifier is not
+ properly handled and would lead to undefined behavior
+
+-
+ Capturless lambdas are not supported and will lead to a compiler error
+ if has_post_decrement is instantiated on the lambda type.
+
+-
+ Scoped enum types are not supported and will lead to a compiler error
+ if has_post_decrement is instantiated on such a type.
+
+
|
diff --git a/doc/html/boost_typetraits/reference/has_post_increment.html b/doc/html/boost_typetraits/reference/has_post_increment.html
index 2331124..c326429 100644
--- a/doc/html/boost_typetraits/reference/has_post_increment.html
+++ b/doc/html/boost_typetraits/reference/has_post_increment.html
@@ -182,6 +182,44 @@
properly handled and would lead to undefined behavior
+
+ Known issues:
+
+
+ For modern compilers (those that support arbitrary SFINAE-expressions and
+ decltype/declval) this trait offers near perfect detection. In this situation
+ the macro BOOST_TT_HAS_ACCURATE_BINARY_OPERATOR_DETECTION
+ will be defined after including <boost/type_traits/has_post_increment.hpp>
.
+ Please note however, that detection is based on function signature only,
+ in the case that the operator is a function template then has_post_increment
+ cannot perform introspection of the template function body to ensure that
+ the type meets all of the conceptual requirements of the actual code.
+
+
+ For older compilers (BOOST_TT_HAS_ACCURATE_BINARY_OPERATOR_DETECTION
+ not defined) then there are a number of issues:
+
+
+-
+ This trait cannot detect whether unary
operator
++
+ is public or not: if operator
++
+ is defined as a private class member of type T then instantiating has_post_increment<T>
+ will produce a compiler error. For this reason has_post_increment
+ cannot be used to determine whether a type has a public operator
++ or not.
+
+-
+
volatile
qualifier is not
+ properly handled and would lead to undefined behavior
+
+-
+ Capturless lambdas are not supported and will lead to a compiler error
+ if has_post_increment is instantiated on the lambda type.
+
+-
+ Scoped enum types are not supported and will lead to a compiler error
+ if has_post_increment is instantiated on such a type.
+
+
|
diff --git a/doc/html/boost_typetraits/reference/has_pre_decrement.html b/doc/html/boost_typetraits/reference/has_pre_decrement.html
index 5bcda06..00a3979 100644
--- a/doc/html/boost_typetraits/reference/has_pre_decrement.html
+++ b/doc/html/boost_typetraits/reference/has_pre_decrement.html
@@ -182,6 +182,44 @@
properly handled and would lead to undefined behavior
+
+ Known issues:
+
+
+ For modern compilers (those that support arbitrary SFINAE-expressions and
+ decltype/declval) this trait offers near perfect detection. In this situation
+ the macro BOOST_TT_HAS_ACCURATE_BINARY_OPERATOR_DETECTION
+ will be defined after including <boost/type_traits/has_pre_decrement.hpp>
.
+ Please note however, that detection is based on function signature only,
+ in the case that the operator is a function template then has_pre_decrement
+ cannot perform introspection of the template function body to ensure that
+ the type meets all of the conceptual requirements of the actual code.
+
+
+ For older compilers (BOOST_TT_HAS_ACCURATE_BINARY_OPERATOR_DETECTION
+ not defined) then there are a number of issues:
+
+
+-
+ This trait cannot detect whether unary
operator
--
+ is public or not: if operator
--
+ is defined as a private class member of type T then instantiating has_pre_decrement<T>
+ will produce a compiler error. For this reason has_pre_decrement
+ cannot be used to determine whether a type has a public operator
-- or not.
+
+-
+
volatile
qualifier is not
+ properly handled and would lead to undefined behavior
+
+-
+ Capturless lambdas are not supported and will lead to a compiler error
+ if has_pre_decrement is instantiated on the lambda type.
+
+-
+ Scoped enum types are not supported and will lead to a compiler error
+ if has_pre_decrement is instantiated on such a type.
+
+
|
diff --git a/doc/html/boost_typetraits/reference/has_pre_increment.html b/doc/html/boost_typetraits/reference/has_pre_increment.html
index b4ab7d3..ba8ef50 100644
--- a/doc/html/boost_typetraits/reference/has_pre_increment.html
+++ b/doc/html/boost_typetraits/reference/has_pre_increment.html
@@ -182,6 +182,44 @@
properly handled and would lead to undefined behavior
+
+ Known issues:
+
+
+ For modern compilers (those that support arbitrary SFINAE-expressions and
+ decltype/declval) this trait offers near perfect detection. In this situation
+ the macro BOOST_TT_HAS_ACCURATE_BINARY_OPERATOR_DETECTION
+ will be defined after including <boost/type_traits/has_pre_increment.hpp>
.
+ Please note however, that detection is based on function signature only,
+ in the case that the operator is a function template then has_pre_increment
+ cannot perform introspection of the template function body to ensure that
+ the type meets all of the conceptual requirements of the actual code.
+
+
+ For older compilers (BOOST_TT_HAS_ACCURATE_BINARY_OPERATOR_DETECTION
+ not defined) then there are a number of issues:
+
+
+-
+ This trait cannot detect whether unary
operator
++
+ is public or not: if operator
++
+ is defined as a private class member of type T then instantiating has_pre_increment<T>
+ will produce a compiler error. For this reason has_pre_increment
+ cannot be used to determine whether a type has a public operator
++ or not.
+
+-
+
volatile
qualifier is not
+ properly handled and would lead to undefined behavior
+
+-
+ Capturless lambdas are not supported and will lead to a compiler error
+ if has_pre_increment is instantiated on the lambda type.
+
+-
+ Scoped enum types are not supported and will lead to a compiler error
+ if has_pre_increment is instantiated on such a type.
+
+
|
diff --git a/doc/html/boost_typetraits/reference/has_unary_minus.html b/doc/html/boost_typetraits/reference/has_unary_minus.html
index a2301a3..3cbcaaa 100644
--- a/doc/html/boost_typetraits/reference/has_unary_minus.html
+++ b/doc/html/boost_typetraits/reference/has_unary_minus.html
@@ -172,6 +172,44 @@
properly handled and would lead to undefined behavior
+
+ Known issues:
+
+
+ For modern compilers (those that support arbitrary SFINAE-expressions and
+ decltype/declval) this trait offers near perfect detection. In this situation
+ the macro BOOST_TT_HAS_ACCURATE_BINARY_OPERATOR_DETECTION
+ will be defined after including <boost/type_traits/has_unary_minus.hpp>
.
+ Please note however, that detection is based on function signature only,
+ in the case that the operator is a function template then has_unary_minus
+ cannot perform introspection of the template function body to ensure that
+ the type meets all of the conceptual requirements of the actual code.
+
+
+ For older compilers (BOOST_TT_HAS_ACCURATE_BINARY_OPERATOR_DETECTION
+ not defined) then there are a number of issues:
+
+
+-
+ This trait cannot detect whether unary
operator
-
+ is public or not: if operator
-
+ is defined as a private class member of type T then instantiating has_unary_minus<T>
+ will produce a compiler error. For this reason has_unary_minus
+ cannot be used to determine whether a type has a public operator
- or not.
+
+-
+
volatile
qualifier is not
+ properly handled and would lead to undefined behavior
+
+-
+ Capturless lambdas are not supported and will lead to a compiler error
+ if has_unary_minus is instantiated on the lambda type.
+
+-
+ Scoped enum types are not supported and will lead to a compiler error
+ if has_unary_minus is instantiated on such a type.
+
+
|
diff --git a/doc/html/boost_typetraits/reference/has_unary_plus.html b/doc/html/boost_typetraits/reference/has_unary_plus.html
index 48be41f..602c37a 100644
--- a/doc/html/boost_typetraits/reference/has_unary_plus.html
+++ b/doc/html/boost_typetraits/reference/has_unary_plus.html
@@ -172,6 +172,44 @@
properly handled and would lead to undefined behavior
+
+ Known issues:
+
+
+ For modern compilers (those that support arbitrary SFINAE-expressions and
+ decltype/declval) this trait offers near perfect detection. In this situation
+ the macro BOOST_TT_HAS_ACCURATE_BINARY_OPERATOR_DETECTION
+ will be defined after including <boost/type_traits/has_unary_plus.hpp>
.
+ Please note however, that detection is based on function signature only,
+ in the case that the operator is a function template then has_unary_plus
+ cannot perform introspection of the template function body to ensure that
+ the type meets all of the conceptual requirements of the actual code.
+
+
+ For older compilers (BOOST_TT_HAS_ACCURATE_BINARY_OPERATOR_DETECTION
+ not defined) then there are a number of issues:
+
+
+-
+ This trait cannot detect whether unary
operator
+
+ is public or not: if operator
+
+ is defined as a private class member of type T then instantiating has_unary_plus<T>
+ will produce a compiler error. For this reason has_unary_plus
+ cannot be used to determine whether a type has a public operator
+ or not.
+
+-
+
volatile
qualifier is not
+ properly handled and would lead to undefined behavior
+
+-
+ Capturless lambdas are not supported and will lead to a compiler error
+ if has_unary_plus is instantiated on the lambda type.
+
+-
+ Scoped enum types are not supported and will lead to a compiler error
+ if has_unary_plus is instantiated on such a type.
+
+
|
diff --git a/doc/html/index/s11.html b/doc/html/index/s11.html
index 43dc946..716068a 100644
--- a/doc/html/index/s11.html
+++ b/doc/html/index/s11.html
@@ -24,7 +24,7 @@
A C D E F H I M N O P R T
-
diff --git a/doc/html/index/s12.html b/doc/html/index/s12.html
index d284d41..fad4f00 100644
--- a/doc/html/index/s12.html
+++ b/doc/html/index/s12.html
@@ -24,7 +24,7 @@
F R T V
-
diff --git a/doc/html/index/s13.html b/doc/html/index/s13.html
index 63a37ae..43d2db5 100644
--- a/doc/html/index/s13.html
+++ b/doc/html/index/s13.html
@@ -24,7 +24,7 @@
B
diff --git a/doc/html/index/s14.html b/doc/html/index/s14.html
index 0439e8b..62efcc3 100644
--- a/doc/html/index/s14.html
+++ b/doc/html/index/s14.html
@@ -23,7 +23,7 @@
A B C D E F H I M N O P R T U V
@@ -389,6 +396,7 @@
has_complement