Re: [Boost-users] [mpl]... is there an mpl::string

Subject: Re: [Boost-users] [mpl]... is there an mpl::string
From: Noah Roberts (roberts.noah_at_[hidden])
Date: 2009-04-08 13:44:05

Eric Niebler wrote:
> Noah Roberts wrote:
>> After reviewing the code it seems that all my concerns are taken care 
>> of.  It looks like it indeed iterates each individual character, not 
>> the multicharacter literals.  It also looks like iterating <'hel', 'lo 
>> w', 'orld', '!'> would be the same as iterating 'hell','o 
>> wo','rld!'>.  So pretty damn cool and some interesting techniques.
>>
>> That said, I would still contemplate pulling the c_str out of the 
>> string container proper.  I would say that the mpl::string is not 
>> similar to the std::string in that it actually has to be transformed 
>> (requiring complete reconstruction) into a c_str; there's nothing 
>> about the mpl::string that renders c_str easier or particular to this 
>> container besides our prebias that it should be.  That alone would 
>> indicate separation to me but additionally if the c_str was a 
>> metafunction separate from the string container, it could be used on 
>> any ForwardSequence.
>>
>> Something to consider anyway.  Thanks for adding this.
> 
> That's not a bad suggestions, and I was on the fence myself about making 
> c_str a class static of mpl::string. My reason for doing so was that 
> getting a C-style string at compile time is really the only reason to 
> use mpl::string, and so accessing it shouldn't incur an extra template 
> instantiation.

Well it wouldn't exactly be 'extra' would it?  The mpl::string itself 
would then never be instantiated since it contains nothing but typedefs 
and such.  You might need to make "size" an enum value...but it should 
be at least possible to make string uninstantiated.
> 
> A separate c_str metafunction might be useful, but to be a proper 
> metafunction, it would need to return a type, not a character array. But 
> as with Integral Constants, we could make:
> 
>   mpl::c_str<FwdSeq>::type::value
> 
> synonymous with:
> 
>   mpl::c_str<FwdSeq>::value
> 
> And mpl::c_str<FwdSeq>::type is probably just a typedef for 
> mpl::c_str<FwdSeq>.

Right, it would be a value metafunction.

> 
> Anyway, I've invested enough time in this already and am happy with the 
> result. If you'd like to see mpl::c_str<>, would you care to submit a 
> patch? Or at least open a feature-request Trac ticket?
> 

I could see about doing it at home but I'm notorious for not doing so. 
Interesting problem though, I might get to it.