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