Andreas Huber wrote: > > It might be possible to fix it, but it will require some work. Let > > me know if it's important for you, and I'll move it up in my TODO > > list. > > Well, it is not that important since mpl::is_sequence<> is only used > to provide some syntactic sugar.
Yep, I understand that; but I was specifically interested whether _incomplete types_ are an important case here. If it's more than just a corner-case situation, I'll look into fixing it. > I could just as well tell my users > that they always have to specify an mpl::list containing a single > type instead of a type under MSVC... But 'is_sequence' does work on MSVC 7.0, in general. So, unless passing an incomplete type is a common-place situation, I would recommend just to document the pitfall itself. > P.S. While making my first serious steps with mpl yesterday, I ran > into some weird errors while trying to compile the following with > MSVC 7.0. Could this also be a limitation of my platform? It was. Fixed now in the CVS. But even on conforming compilers, the following line is currently problematic, because of the maximum arity limit on metafunctions that can participate in lambda expressions: typedef boost::mpl::transform< trans_list, boost::mpl::apply< _, Running > >::type handler_list; Since, under the cover, the main 'apply' template has BOOST_MPL_METAFUNCTION_MAX_ARITY + 1 template parameters, it fails to be properly handled by the lambda facility, causing the code to fail. A short-term workaround is to use a numbered 'apply' form instead - in your case, 'apply1'. I'll look into fixing the problem for the upcoming release. Aleksey _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost