Boost logo

Boost :

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2004-10-25 12:50:39


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
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk