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

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-03-03 19:20:22

David Abrahams wrote:
> 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.
> 

Here's the output of the above program in case you don't have a gcc 
handy to convince yourself:

tmp.cpp:12: error: conversion from 
`mpl_::failed************boost::mpl::equal<v, boost::mpl::vector3<bool, 
char, int>, boost::is_same<mpl_::_, mpl_::_> >::************' to 
non-scalar type `mpl_::assert< false>' requested
tmp.cpp:12: error: enumerator value for `mpl_assertion_in_line_14' not 
integer constant

> 
> 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).
> 

Problems resulting from this are for sure vicious to track...

Note that 'pop_front' is arbitrary - it applies to all front/back mutators.

Regards,

Tobias