Eric, I would be interested in that too. I already had to code around in a project, to make smth. similar. Would be nice to have it in MPL. Many thanks, Ovanes On Mon, Mar 30, 2009 at 5:58 AM, Eric Niebler wrote:

Andy Stevenson wrote:

...

Hi,

I recall some discussion of there being an mpl::string template..... Can't see it in the mpl library. Is it elsewhere?

I wrote one once and intended to write docs and tests and integrate it into MPL but never got around to it. You can find it here:

http://archives.free.net.ph/message/20080324.060757.9880ea2b.el.html

-- Eric Niebler BoostPro Computing http://www.boostpro.com

...

...

Andy Stevenson wrote:

...

I recall some discussion of there being an mpl::string template..... Can't see it in the mpl library. Is it elsewhere?

It has been added to trunk as of revision 52208: https://svn.boost.org/trac/boost/changeset/52208 No doubt the regression tests will reveal portability problems. Once they have been worked out, we can move this to release. -- Eric Niebler BoostPro Computing http://www.boostpro.com

Noah Roberts wrote:

Eric Niebler wrote:

...

...

...

...

Andy Stevenson wrote:

...

I recall some discussion of there being an mpl::string template..... Can't see it in the mpl library. Is it elsewhere?

It has been added to trunk as of revision 52208:

https://svn.boost.org/trac/boost/changeset/52208

No doubt the regression tests will reveal portability problems. Once they have been worked out, we can move this to release.

Why is this better than a metafunction c_str< Sequence >?

typedef mpl::vector_c str;

template < char const* sz > struct x {};

x< c_str<str>::value > test;

Is there some reason that's not possible or is prone to problems avoided by mpl::string?

That is certainly a valid design. It's somewhat subjective, but IMO multi-character literals give a nicer compile-time string interface. Consider: // With mpl::vector_c mpl::vector_c // With mpl::string mpl::string<'hell','o wo','rld'> Neither will win a beauty contest, but my preference is strongly for the latter. -- Eric Niebler BoostPro Computing http://www.boostpro.com

Dominique Devienne wrote:

On Tue, Apr 7, 2009 at 12:21 PM, Eric Niebler wrote:

...

multi-character literals give a nicer compile-time string interface. // With mpl::string mpl::string<'hell','o wo','rld'>

Hi Eric,

I've been lurking on this thread for a while, and I'm intrigued by "multi-character literals". Beside being new to me, a Google search yields little information on them, beside the fact that "The value of a narrow or wide character literal containing more than one character or escape sequence is implementation-defined." Isn't this a problem for mpl::string? Thanks, --DD

"Implementation-defined" means that each compiler vendor is required to document how multi-character literals are assigned integral values. A library like MPL can use this information to provide a specialized implementation for each compiler, presenting the user with a uniform interface. And as it turns out, there is very little variation among compiler vendors around the handling of multi-character literals. So far, just one implementation has sufficed. -- Eric Niebler BoostPro Computing http://www.boostpro.com

On Wed, Apr 8, 2009 at 6:09 PM, 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.

I agree with Noah. One more question, can you point to the compiler docs which you used as reference? I am just interested to read this it for my own. Many thanks, Ovanes

On Wed, Apr 8, 2009 at 6:57 PM, Eric Niebler wrote:

You mean, how did I discover the nature of the implementation-defined behavior for each compiler? It wasn't by reading any docs. I just played around with various compilers until I found what worked. I found some compiler bugs in the process, too. See:

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Feedba...

Interesting. Ok, but if a string maps to an integer it means that I can only pass 4 characters at once on a 32bit platform??? I just looked over your tests and did not get immediately that these all use char test sequences. I used a slightly different approach in my previous use case. template string {...}; extern const char some_string[] ={"abcd efg..."}; typedef string my_string_type; Would be cool to find a solution of really passing strings like: typedef string<"abcd efg.."> some_other_type; Regards, Ovanes

On Wed, Apr 8, 2009 at 7:51 PM, Eric Niebler wrote:

Ovanes Markarian wrote:

...

Eric Niebler wrote:

...

You mean, how did I discover the nature of the implementation-defined behavior for each compiler? It wasn't by reading any docs. I just played around with various compilers until I found what worked. I found some compiler bugs in the process, too. See:

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Feedba...

Interesting. Ok, but if a string maps to an integer it means that I can only pass 4 characters at once on a 32bit platform???

Strings don't map to integers. Multicharacter literals do. And yes, that means in general that you can only reliably count on being able to encode a 4 char sequence in a multicharacter literal.

Yes, sure. It is already late in Munich and I have headache. I meant exactly that.

I just looked over your tests and did not get immediately that these

...

all use char test sequences.

I don't follow you.

Sorry again. I mean that your tests are based on 4-char literals, which I did not pay attention.

I used a slightly different approach in my previous use case.

...

template string {...};

extern const char some_string[] ={"abcd efg..."};

typedef string my_string_type;

Sure, but that gets hard to use, and you can't use this to compute new strings at compile time.

:) But for my special use case that was enough. I defenitely share your opinion, that a library implementation should be more flexible, than my special use case impl was. On the other hand I too oft see programmers which are ignorant and even don't give a chance to a great approach. I can imagine their reaction when seeing: typdef mpl::string<'some', 'cool', 'type'> compile_time_string;

Would be cool to find a solution of really passing strings like:

...

typedef string<"abcd efg.."> some_other_type;

And if wishes were fishes we'd all cast nets. ;-)

Would be nice to get there ;) Cheers, Ovanes

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.

Eric Niebler wrote:

There's another consideration that I've been glossing over. mpl::string isn't *really* random access. Since mpl::string<'a','b','c'> designates the same character sequence as mpl::string<'abc'>, it takes O(N) template instantiations to find the N-th element in the sequence, at least in the current implementation. I'd like to fix that, but I don't know how (yet).

Now this is really bothering me. The right thing to do is replace the current implementation with one in which mpl::string is a front- and back-extensible bidirectional sequence, and give up with the random access pretense. :-( -- Eric Niebler BoostPro Computing http://www.boostpro.com

On Sat, 11 Apr 2009 01:36:11 -0500, Eric Niebler wrote:

I've made this change. mpl::string is no longer random access (it never really was). Also, I've changed c_str to be a separate metafunction that works with any forward sequence.

Thanks particularly to Noah Roberts for the good feedback.

Nice work, guys! -- Aleksey Gurtovoy MetaCommunications Engineering

On Mon, Apr 13, 2009 at 5:45 PM, Noah Roberts wrote:

Eric Niebler wrote:

...

Eric Niebler wrote:

...

Eric Niebler wrote:

...

There's another consideration that I've been glossing over. mpl::string isn't *really* random access. Since mpl::string<'a','b','c'> designates the same character sequence as mpl::string<'abc'>, it takes O(N) template instantiations to find the N-th element in the sequence, at least in the current implementation. I'd like to fix that, but I don't know how (yet).

Now this is really bothering me. The right thing to do is replace the current implementation with one in which mpl::string is a front- and back-extensible bidirectional sequence, and give up with the random access pretense. :-(

I've made this change. mpl::string is no longer random access (it never really was). Also, I've changed c_str to be a separate metafunction that works with any forward sequence.

Thanks particularly to Noah Roberts for the good feedback.

No problem.

Now someone just needs to make format<> :P

Although a tongue-in-cheek remark, the notion of a compile-time formatting library somehow appeals to me, if for nothing else for its sheer absurdity ;) Due to the limits of preprocessor stringization when dealing with metaprogramming integers, I suspect it might have its use cases wherever runtime conversion overhead is best avoided. With mpl::string it's trivial to create integer-to-string conversion metafunctions, and it should also not be overly complicated to glue these together into something bigger if so should desired. I whipped up a quick (and not very pretty) compile-time _itoa equivalent as a small proof of concept just for fun (only tested on visual c++ 2008) #include <iostream> #include #include #include #include #include #include #include #include namespace mpl = boost::mpl; struct itoa_ct { // radix for _itoa() goes up to 36, but only bother with 16 here typedef mpl::vector_c

radix_t;

template struct radix_convert { typedef typename mpl::push_back< typename radix_convert::type , mpl::char_::type::value> >::type type; }; template <int Radix> struct radix_convert { typedef mpl::string<> type; }; template struct apply { // All bases != 10 consider I as unsigned typedef typename radix_convert< Radix, static_cast<unsigned int>((Radix == 10 && I < 0) ? -I : I) >::type converted_t; // Prefix with '-' if negative and base 10 typedef typename mpl::if_< mpl::bool_<(Radix == 10 && I < 0)> , mpl::push_front > , mpl::identity >::type::type type; }; }; int main(int argc, char* argv[]) { std::cout << mpl::c_str::type>::value << "\n"; std::cout << mpl::c_str::type>::value << "\n"; std::cout << mpl::c_str::type>::value << "\n"; std::cout << mpl::c_str::type>::value << "\n"; std::cout << mpl::c_str::type>::value << "\n"; return 0; } which outputs, as expected: 12345 -98765 11111011001 b0057 ffffffff I'm swamped with thesis-work until June, so I cannot really do much else with this for now, but I just wanted to throw it out there. Any thoughts? :) Regards, Tor Brede Vekterli

Eric Niebler wrote:

...

...

...

Andy Stevenson wrote:

...

I recall some discussion of there being an mpl::string template..... Can't see it in the mpl library. Is it elsewhere?

It has been added to trunk as of revision 52208:

https://svn.boost.org/trac/boost/changeset/52208

No doubt the regression tests will reveal portability problems. Once they have been worked out, we can move this to release.

Visual Studio 2005 hates it. Perhaps I'm not going about it the right way? I simply downloaded string.hpp, char.hpp, and char_fwd.hpp and altered the include paths so that they'd work in an individual project. Then I wrote the following test code: #include <iostream> #include "string.hpp" template < char const* str > struct test { static void print() { std::cout << str << std::endl; } }; int main() { typedef boost::mpl::string<'hell', 'o wo', 'rld!'> str; std::cout << str::template at<0>::value << std::endl; std::cin.get(); } 1>e:\dev_workspace\experimental\scratch\scratch\main.cpp(15) : error C2976: 'boost::mpl::string::at' : too few template arguments 1> with 1> [ 1> C0=1751477356, 1> C1=1864398703, 1> C2=1919706145 1> ] This of course causes problems in c_str. This code fails for the same reason: #include <iostream> #include template < typename T > struct test_inner { template < typename X, bool B = boost::is_same::value > struct inner { static bool const value = B; }; }; int main() { std::cout << test_inner<int>::template inner<int>::value << std::endl; std::cin.get(); } So, looks like VS can't handle default template arguments in these inner templates. I changed the implementation of at<>: template < typename String, long Pos, bool B = (Pos < BOOST_MPL_MULTICHAR_LENGTH(String::front_)) > struct string_at : boost::mpl::char_ { }; template < typename String, long Pos > struct string_at : string_at< typename String::rest_, Pos - BOOST_MPL_MULTICHAR_LENGTH(String::front_)> { }; template<> struct at_impl { template struct apply : string_at {}; }; And implemented c_str[] in terms of string_at<>: template char const string::c_str[] = { #define M0(z, n, data) string_at, n>::value BOOST_PP_ENUM(BOOST_MPL_STRING_MAX_LENGTH, M0, ~) #undef M0 , '\0' // to ensure the string is null-terminated }; This code compiles with changes in VS 2005: #include <iostream> #include #include #include "string.hpp" int main() { typedef boost::mpl::string<'hell', 'o wo', 'rld!'> str; std::cout << boost::mpl::at >::value << std::endl; std::cout << str::c_str << std::endl; std::cin.get(); }

Eric Niebler wrote:

Noah Roberts wrote:

...

Eric Niebler wrote:

...

...

...

...

Andy Stevenson wrote: > > I recall some discussion of there being an mpl::string > template..... Can't see it in the mpl library. Is it elsewhere?

It has been added to trunk as of revision 52208:

https://svn.boost.org/trac/boost/changeset/52208

No doubt the regression tests will reveal portability problems. Once they have been worked out, we can move this to release.

Visual Studio 2005 hates it.

<snip>

Is that msvc-7.1? If so, I have already fixed the problem in changeset 52241. You can see that the string tests are passing for msvc-7.1, -8.0 and -9.0 by looking at the regression results.

No, it's msvc-8.0 Regression results aside, this doesn't compile: #include <iostream> #include #include #include int main() { typedef boost::mpl::string<'hell', 'o wo', 'rld!'> str; std::cout << boost::mpl::at >::value << std::endl; std::cout << str::c_str << std::endl; std::cin.get(); } Again, I simply copied char.hpp, char_fwd.hpp, and string.hpp into boost 1.37 It could be that it's because I'm not grabbing the entire boost tree from svn but since I can replicate the problem with a basic program that's using the same techniques you are, I really doubt that. Looking deeper, you need to change: #if BOOST_WORKAROUND(BOOST_MSVC, == 1310) to: #if BOOST_WORKAROUND(BOOST_MSVC, <= 1400) Alternatively, you could just keep telling me it's working and I'll go away. I'm not loaded with a lot of spare time either.

Thanks Eric.... would be a useful addition to mpl I think at some point. Great for DSLs which is how I intend to use it. Andy On 30 Mar 2009, at 04:58, Eric Niebler wrote:

Andy Stevenson wrote:

...

Hi, I recall some discussion of there being an mpl::string template..... Can't see it in the mpl library. Is it elsewhere?

I wrote one once and intended to write docs and tests and integrate it into MPL but never got around to it. You can find it here:

http://archives.free.net.ph/message/20080324.060757.9880ea2b.el.html

-- Eric Niebler BoostPro Computing http://www.boostpro.com

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users