Re: [boost] [mpl] mpl::c_str fails for mpl::push_back

Subject: Re: [boost] [mpl] mpl::c_str fails for mpl::push_back
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-11-07 02:38:05

----- Original Message ----- 
From: "Eric Niebler" <eric_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Sunday, November 07, 2010 2:15 AM
Subject: Re: [boost] [mpl] mpl::c_str fails for mpl::push_back

> 
> On 11/6/2010 8:51 PM, vicente.botet wrote:
>> Hi,
>> 
>> the following results in a compile error for msvc-10.0. It works for gcc-3.4, gcc-4.3, gcc-4.5.
>> 
>> typedef mpl::vector_c<char, 'h','e','l','l','o',' ','w','o','r','l','d'> hello;
>> 
>> typedef mpl::push_back<hello, mpl::char_<'!'> >::type hello2;
>> 
>> BOOST_TEST((std::string(mpl::c_str<hello2>::value)== "hello world!")); // line 59
>> 
>> C:\cygwin\boost\v44\boost/mpl/string.hpp(592) : error C2039: 'value_type' : is not a member of 'boost::mpl::vector12<T0,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11>'
>> Is this a known bug? 
> 
> 
> mpl::c_str is for use with mpl::string. Does the problem also occur with
> mpl::string?

No push_back on a mpl::string is works as it is yet a Integral Sequence Wrapper. But push_back on a vector_c which is a Integral Sequence Wrapper is not a Integral Sequence Wrapper and this seems to me a more critical issue.

BOOST_STATIC_ASSERT((boost::is_same<hello2::value_type,char>::value)); // compile fail

I was loking for a way to represent static sequences of arbitrary chararcters types and mpl::string doesn't supports wchar_t, u16char or u32char so I though to move to vector_c.

BTW, I have found the use of c_str in a MPL tests string.cpp  

    typedef mpl::vector_c<char, 'a','b','c','d','e'> rgc;
***    BOOST_TEST(0 == std::strcmp("abcde", mpl::c_str<rgc>::value));
    typedef mpl::copy<rgc, mpl::back_inserter<mpl::string<> > >::type str;
    BOOST_TEST(0 == std::strcmp("abcde", mpl::c_str<str>::value));

I don't think I could find something in the doc that states that the push_back on a Integral Sequence Wrapper must be a Integral Sequence Wrapper, but I think that this is a desirable property. 

Do you have a workaround I can use to preserve it?
Do you think that it is possible to ensure that property without too much trouble inside the library?

Thanks, 
Vicente