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

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2004-09-14 17:53:53

>From: "Alex Chovanec" <chovanec_at_[hidden]>

> Terje Slettebø <tslettebo_at_[hidden]> writes:
>
> > 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.

Exactly. If you look at the implementation of the traits in the library I
uploaded, e.g. has_plus_op, you'll see that it has a two-part
implementation: The first part "filters" the types (using type traits and
MPL's logical metafunctions, not specialisations), and it ends with
"detail::has_plus_op_impl<T,U>". Only if it passes the first part, will it
attempt this final check, where it tries to perform T1 + T2 (with the
...-overload if there's no existing operator+ for them). The first filtering
ensures that - as you say about dereferencing the fundamental types - it
doesn't try to do e.g. void + void, because that will fail with an error,
regardless of the ...-overload (overloaded functions are not considered for
built-in types).

On the surface, it may seem logical that it should be possible to write a
"generic macro" for all operators, but when you get down to actually doing
it, and testing it against all kinds of types, you find that you need this
"pre-filtering" phase to avoid errors, and as you also point out, that phase
is different for different operators. It's not as "easy" as it may seem.

Regards,

Terje