Nested If in boost:mpl::if_

hi all
I am trying to use mpl to do some simple type computation that involves nest
if statements
The logic is somewhat like
if(T is Libor)
return LiborType
if(
or(
or(T = Euribor,
T = EURLibor),
is_base_of(T, Libor)
),
ConstrType2,
if(
or(is_base_of(T, Euribor),
is_base_of(T, EURLibor)),
ConstrType1,
ConstrType
)
)
When I first coded it and instantiate T with some derived class of
Libor, the final type is always a generic type. Few more testing shows
that the inner if_ in the code below
typedef typename
boost::mpl::if_
<
boost::is_same

On Thu, Dec 2, 2010 at 3:09 PM, Leon Sit
does not reduce to ConstrType1/ConstrType2/ConstrType but the whole is used as a type. So the final Type is just a type with 3 nested if_ class inside. I tried linearising the logic but this introduces other problem. Is this a bug or a limitation of mpl::if_?
_______________________________________
Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
It's not a limitation of mpl::if_, it's doing exactly what you are telling it to do. What you actually want is to have your top-level mpl::if to actually be mpl::eval_if, and you should be wrapping the second parameter, "QuantLib::Libor" in mpl::identity. eval_if will automatically yield the nested type of the result, which is necessary if you want the result of the top-level condition to be the result of an inner conditions (otherwise, the result of the top-level condition will be the inner condition itself, which is what you see). This has effectively the same result as not using eval_if, but still using mpl::identity as I described only having "::type::type" as opposed to "::type" at the end. -- -Matt Calabrese
participants (2)
-
Leon Sit
-
Matt Calabrese