Re: [boost] [string] proposal

Subject: Re: [boost] [string] proposal
From: David Bergman (David.Bergman_at_[hidden])
Date: 2011-01-27 12:43:16

On Jan 27, 2011, at 5:52 AM, Dean Michael Berris wrote:

> On Thu, Jan 27, 2011 at 4:09 PM, Artyom <artyomtnk_at_[hidden]> wrote:

[snip]

>> 3. What so painful problems are you going to solve that
>>   would make it so much better then widely used and adopted
>>   std::string? Iterators? Mutability? Performance?
>> 
>>   (Clue: there is no painful problems with std::string)
>> 
> 
> Sorry, but for someone who's dealt with std::string for *a long time
> (close to 8 years)* here's are a few real painful problems with it:

I actually agree with you here, DMB (which are also my initials...), although I am still in shock of this "new IT world" where 8 years is a long time :-) Some old farts here (me included) have dealt with std::string for 20+ years, and, yes, we share your pain :-)

Artyom is a bit silly here, since "having to know the encoded length of each character and then use some calculus to get to the index to use when setting a character" is indeed a problem for a client of a class - one does want that intelligence to be embedded in a proper string class. Yes, there are cases for UTF-8, specifically, where we can just watch for a certain byte coming up, but that is not a stable pattern and applies only to certain operations, such as his searching for whitespace.

Additionally, not only having dealt with std::string for more than 20 years but also with Java, C#, Ruby etc. [sS]trings for the last 10-15 years, it is quite clear that not having a string class in the standard library that can at least handle UTF-8 properly is a wart and an embarrassment when trying to lure "soft programmers" into C++. One has to come up with defenses like those of Artyom's to salvage the situation...

So, I applaud your fight here, DMB, seriously. I just happen to disagree with your specific focus.

What I would do would be to focus not on a class per se but on the (GP...) concept and the associated iterators needed. Then we can see if we can also produce a proper model for that, or if we can find a sub concept (even though it would only be "sub" specification-wise but actually "super" set-wise...) that would make the current std::string a model.

And, I would drop the "immutable" part since this thread was supposed to be about a new thingie that could potentially replace std::string in C++3x..

/David