Boost logo

Boost :

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
> 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.



Boost list run by bdawes at, gregod at, cpdaniel at, john at