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

Renamed member check to avoid conflict with MacOS macro of the same name.

Browse Source 
[SVN r22890]
This commit is contained in:
John Maddock
2004-05-22 10:36:05 +00:00
parent 39ce140cf7
commit b3d31b8e24
2 changed files with 12 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
include/boost/type_traits/is_abstract.hpp
View File

@ -61,16 +61,16 @@ struct is_abstract_imp
// according to review status issue #337
//
template<class U>
static type_traits::no_type check(U (*)[1]);
static type_traits::no_type check_sig(U (*)[1]);
template<class U>
static type_traits::yes_type check(...);
static type_traits::yes_type check_sig(...);
// GCC2 won't even parse this template if we embed the computation
// of s1 in the computation of value.
#ifdef __GNUC__
BOOST_STATIC_CONSTANT(unsigned, s1 = sizeof(is_abstract_imp<T>::template check<T>(0)));
BOOST_STATIC_CONSTANT(unsigned, s1 = sizeof(is_abstract_imp<T>::template check_sig<T>(0)));
#else
BOOST_STATIC_CONSTANT(unsigned, s1 = sizeof(check<T>(0)));
BOOST_STATIC_CONSTANT(unsigned, s1 = sizeof(check_sig<T>(0)));
#endif
BOOST_STATIC_CONSTANT(bool, value =

16
include/boost/type_traits/is_base_and_derived.hpp
View File

@ -56,18 +56,18 @@ UDC - User-defined conversion
A user-defined conversion sequence consists of an SC, followed by an UDC,
followed by another SC. Either SC may be the identity conversion.
When passing the default-constructed Host object to the overloaded check()
When passing the default-constructed Host object to the overloaded check_sig()
functions (initialization 8.5/14/4/3), we have several viable implicit
conversion sequences:
For "static no_type check(B const volatile *, int)" we have the conversion
For "static no_type check_sig(B const volatile *, int)" we have the conversion
sequences:
C -> C const (SC - Qualification Adjustment) -> B const volatile* (UDC)
C -> D const volatile* (UDC) -> B1 const volatile* / B2 const volatile* ->
B const volatile* (SC - Conversion)
For "static yes_type check(D const volatile *, T)" we have the conversion
For "static yes_type check_sig(D const volatile *, T)" we have the conversion
sequence:
C -> D const volatile* (UDC)
@ -91,12 +91,12 @@ eliminated before it could possibly cause ambiguity or access violation.
If D is not derived from B, it has to choose between C -> C const -> B const
volatile* for the first function, and C -> D const volatile* for the second
function, which are just as good (both requires a UDC, 13.3.3.2), had it not
been for the fact that "static no_type check(B const volatile *, int)" is
been for the fact that "static no_type check_sig(B const volatile *, int)" is
not templated, which makes C -> C const -> B const volatile* the best choice
(13.3.3/1/4), resulting in "no".
Also, if Host::operator B const volatile* hadn't been const, the two
conversion sequences for "static no_type check(B const volatile *, int)", in
conversion sequences for "static no_type check_sig(B const volatile *, int)", in
the case where D is derived from B, would have been ambiguous.
See also
@ -109,8 +109,8 @@ template <typename B, typename D>
struct bd_helper
{
template <typename T>
static type_traits::yes_type check(D const volatile *, T);
static type_traits::no_type check(B const volatile *, int);
static type_traits::yes_type check_sig(D const volatile *, T);
static type_traits::no_type check_sig(B const volatile *, int);
};
template<typename B, typename D>
@ -123,7 +123,7 @@ struct is_base_and_derived_impl2
};
BOOST_STATIC_CONSTANT(bool, value =
sizeof(bd_helper<B,D>::check(Host(), 0)) == sizeof(type_traits::yes_type));
sizeof(bd_helper<B,D>::check_sig(Host(), 0)) == sizeof(type_traits::yes_type));
};
#else