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. 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>. 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? -- Eric Niebler BoostPro Computing http://www.boostpro.com