[boost] Re: [mpl-docs] portability trap

From: David Abrahams (dave_at_[hidden])
Date: 2005-03-03 17:49:35

Tobias Schwinger <tschwinger_at_[hidden]> writes:

> Hi,
>
> This code:
>
> #include <boost/mpl/vector.hpp>
> #include <boost/mpl/pop_front.hpp>
> #include <boost/mpl/assert.hpp>
> #include <boost/mpl/equal.hpp>
>
> using namespace boost;
>
> // Doc says: pop_front returns a vector
> typedef mpl::pop_front< mpl::vector<bool,char,int> >::type v;
>
> // Doc says: vectors have a type member equal to itself
> BOOST_MPL_ASSERT((
>   mpl::equal< v, v::type >
> ));
>
> fails to compile with GCC ( v::type is mpl::vector3<bool,char,int> ) 

That's a bug.  If that's truly happening, the documentation is correct
and the implementation is wrong.

> and compiles fine with other compilers.
>
> Examples for false conclusions that could be easily drawn from the 
> current documentation:
>
>  "Oh great - I do not need mpl::identity when using v with
>   mpl::eval_if"
>
>  "Let's inherit from 'v::type' so I can save the '::type' later"
>
>  "::type always gives the numbered form of my current sequence so
>   I can use it with partial specialization"
>
> I got trapped by this in two different places (and I still hope not to 
> be surpassingly stupid ;-). Shouldn't this behaviour be documented in 
> some way ?

No, it should be fixed.

  mpl::pop_front< mpl::vector<bool,char,int> >::type::type

should always be a sequence of length 2 containing (char, int).

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com