From: Alex Chovanec (chovanec_at_[hidden])
Date: 2004-09-14 15:37:07
Terje Slettebø <tslettebo_at_[hidden]> writes:
> There are also similar facilites as
> BOOST_IS_XXXABLE_PREFIX()/BOOST_IS_XXXABLE_POSTFIX() in the
operator/concept
> traits library, although they are not documented, as such detection for
all
> the overloadable operators is already defined in the library, so the user
> shouldn't really have a need for it. Nevertheless, they are found in the
> operator_traits/detail/unop.hpp (prefix), unop2.hpp (postfix) and
binop.hpp
> headers.
> The current version of is_xxxable.hpp in Yahoo Files does seem to have
some
> problems, when it comes to implicit conversions.
I discovered another problem with these macros after I uploaded them. The
original 'is_dereferenceable' implementation relied upon special handling
for fundamental types. The reason is that attempting to dereference
something like an 'int' or 'float' is going to cause a compiler error no
matter what, even if there is a last resort 'operator*'. To solve this
problem, I rigged 'is_dereferenceable' to return false for all fundamental
types. (Pointers are not considered fundamental types.) This special
handling was carried over into the 'is_xxxable' macros, and it doesn't
generalize to other operators. For instance, if I use
'BOOST_IS_XXXABLE_PREFIX' to generate 'is_incrementable', I get a
metafunction that returns 'false' for integers.
Of course, this problem can be fixed, but probably not without some special
handling for specific fundamental types and/or operators, which kind of
defeats the purpose of having a generalized macro.
-- Alex Chovanec NIF and Engineering Division Computing Applications and Research Department Lawrence Livermore National Laboratory