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-08 11:29:55

----- Original Message ----- 
From: "Aleksey Gurtovoy" <agurtovoy_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, November 08, 2010 10:47 AM
Subject: Re: [boost] [mpl] mpl::c_str fails for mpl::push_back

> 
> On Sun, 07 Nov 2010 01:38:05 -0600, vicente.botet  
> <vicente.botet_at_[hidden]> wrote:
>> 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.
> 
> It might seem so on the surface, but consider this:
> 
>    typedef push_back< rgc, long_<MAX_LONG> >::type v;
> 
> or this:
> 
>    typedef push_back< rgc, struct my >::type v;

I see. I was thinking on homogeneous constainer and mpl sequences are by nature heterogeneous.
 
>> 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?
> 
> It's certainly possible, but it would also certainly complicate things. At  
> the moment it seems to me to be too special of a case to be worth the  
> trouble.

I understand. This would mean to have two families of sequences the current ones which are heretogeneus, and other that will accept some kind of hogeneity, but as you say this will complicat things too much.

Thanks,
Vicente