Robert Ramey writes:

The serialization library is failing all tests with IBM visual age compiler. Errors occur within mpl.

Not quite, I am afraid. Considering that the 'apply_if' test itself compiles without an error, this looks more like a problem with the particular context where the facility is used: "/home/tk/boost_regression/boost/boost/serialization/level.hpp", line 44.9: 1540-0038 (S) The name "typename mpl::apply_if< boost::is_base_and_derived< boost::serialization::basic_traits, boost::serialization::nvp<A[9]> >, boost::serialization::implementation_level< boost::serialization::nvp<A[9]> >::traits_class_level< boost::serialization::nvp<A[9]> >, boost::mpl::int_<3> >::type" is not a type. Looking at the code in "level.hpp", this is one complicated typedef! typedef BOOST_DEDUCED_TYPENAME mpl::apply_if< is_base_and_derived<basic_traits, T>, traits_class_level<T>, //else BOOST_DEDUCED_TYPENAME mpl::apply_if< is_fundamental<T>, mpl::int_<primitive_type>, //else BOOST_DEDUCED_TYPENAME mpl::apply_if< is_class<T>, mpl::int_<object_class_info>, //else BOOST_DEDUCED_TYPENAME mpl::apply_if< is_array<T>, #if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x564)) mpl::int_<not_serializable>, #else mpl::int_<object_serializable>, #endif //else BOOST_DEDUCED_TYPENAME mpl::apply_if< is_enum<T>, #if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x564)) mpl::int_<not_serializable>, #else mpl::int_<object_serializable>, #endif //else mpl::int_<not_serializable> >::type >::type >::type >::type >::type type; It's inefficient, too (you don't need all these '::type's except the very last one), but in any case: I think the most practical way to approach the error is to simplify the above to the bare minimum (ignoring the semantics for now), and see how the compiler reacts. For instance, #if BOOST_WORKAROUND(__IBMCPP__, BOOST_TESTED_AT(600)) typedef BOOST_DEDUCED_TYPENAME mpl::apply_if< is_base_and_derived<basic_traits, T>, traits_class_level<T>, mpl::int_<object_serializable> >::type type; #else // original code ... #endif

a) Can any one give me some hints to try to address this?

I am afraid the only thing we can do here is to tweak the code in a few different ways and see how it affects the compiler -- unless somebody else is familiar with the issue.

b) Is there not a new version of mpl that is going to uploaded.

Yes...

Maybe if I just wait things will improve?

... and no -- I don't think that it's strictly an MPL problem, and even if it is, the earlier we start searching for a workaround the more chances we have to fix it before the release. -- Aleksey Gurtovoy MetaCommunications Engineering