[boost] Re: Re: Constrained genericity at last? (any interest inanoperator traits/concept traits library?)

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