On Wed, Apr 8, 2009 at 7:51 PM, Eric Niebler <eric@boost-consulting.com> 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?FeedbackID=334208

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<char const* Str> string {...};

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

typedef string<some_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