I've been investigating the problem a little further, and the final results are these: Seems like handling of MPL lambda expressions is difficult with GCC 2.95. The following snippet: typedef transform1< vector<char,int,double>, XXX
::type t1;
has several outcomes depending on XXX 1. identity<_1>: OK 2. mpl::sizeof<_1>: complains about an expression not being constant. However, code like this is embedded into Boost.Variant and seems to work fine (??) 3. boost::alignment_of<_1>: ICEs like I previously described. This is the error Boost.Variant is currently running into. My skills are too limited to be able to find a reason for this behavior, so I hope people smarter than me can do something with this. In case this problem is finally *not* taken care of, I've managed to workaround the regressions in Boost.Variant with a patch to be applied to boost/variant/variant.hpp (attached). Basically, the patch avoids the use of boost::aligment_of<_1> in favor of a more traditional metafunction class. So, if someone is able to fix this problem by touching either MPL or type_traits, so much the better. Otherwise, does anybody see a problem with me commiting the patch to Boost.Variant? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 206a207,226
#if BOOST_WORKAROUND(__GNUC__, <3)
/////////////////////////////////////////////////////////////////////////////// // (detail) metafunction alignment_of_helper // // GCC 2.95 ICEs under some circumsntances when using the lambda // expression alignment_of<mpl::_1>. alignment_of_helper is an equivalent // metafunction class. //
struct alignment_of_helper { template <typename T> struct apply: boost::alignment_of<T> { }; };
#endif // gcc 2.95
233a254,257
#if BOOST_WORKAROUND(__GNUC__, <3) types, alignment_of_helper // see description of alignment_of_helper #else
234a259,260
#endif