Boost logo

Boost :

From: Jaap Suter (J.Suter_at_[hidden])
Date: 2002-09-18 16:27:10


consider the following code:

apply_if< some_condition,

We do this because we don't want some_type_2 evaluated if some_condition is
true, or vice versa. Very handy and I need it a lot. However, consider the
following case:

apply_if< some_condition,
               plus< some_type_2::type, some_number >

In this case, I get the impression that my compiler (Intel) evaluates the
template parameters of plus, and thus of some_type_2::type, even when it is
not used. However, as in the mpl::apply_if rationale, this may not always

Thus, I provide the following indirection:

template< ... >
struct recurse
    typedef plus< some_type_2::type, some_number > type

apply_if< some_condition,

And now it works, because the compiler no longer evaluates the
some_type_2::type, if it is not needed.

Now, I have the following questions:

1. Can you acknowledge this problem? The fact that the compiler evaluates
template parameters for non-used types, and consequently that the
rationale applies here as well?

2. Is this the best solution to solve this problem?

3. Maybe we can introduce the indirection in plus and other meta-functions
that act on integral constants directly. Allow me to explain:

integral_c and the other (bool_c, int_c, etc.) all support the ::type
construct that reflects upon itself. We can use this to allow plus (for
example) to always query its arguments for the type.

Current mpl::plus implementation:

template< typename A, typename B >
struct plus
    typedef integral_c< A::value_type, A::value + B::value > type;

My proposed mpl::plus implementation:

template< typename A, typename B >
struct plus
    typedef integral_c< A::type::value_type, A::type::value + B::type::value
> type;

This allows us to pass unfinished expressions into meta-functions. A sort of
lazy evaluation. Using this, my second code example could have been written

apply_if< some_condition,
               plus< some_type_2, some_number >

and would have worked.

However, I agree that this is a bit ugly. For example, why limit this to
only one -type depth? Why not call ::type on the incoming parameters until
we reach a type that has a ::value parameter? I don't know. Perhaps my
suggested work-around using the recurse helper-meta-function is better.

Anyway, just some questions, comments and ideas....

Thanks and regards,

Jaap Suter

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