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<InType, QuantLib::Libor>, QuantLib::Libor, boost::mpl::if_ < boost::mpl::or_ < boost::is_same<InType, QuantLib::Euribor>, boost::is_same<InType, QuantLib::EURLibor>, boost::is_base_of<QuantLib::Libor, InType> > ConstrType2, boost::mpl::if_ < boost::mpl::or_ < boost::is_base_of<QuantLib::Euribor, InType>, boost::is_base_of<QuantLib::EURLibor, InType> >, ConstrType1, ConstrType > > >::type Type; 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_? Thanks
On Thu, Dec 2, 2010 at 3:09 PM, Leon Sit <wing1127aishi@gmail.com> wrote:
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