From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2003-02-06 06:50:36
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:
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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk