Adding moving to basic_string

[chris jefferson <caj at cs dot york dot ac dot uk>]

Paolo Carlini wrote:

> We have also to start thinking about basic_string. N1377 and N1699 are
>
> definitely very interesting about that. All in all, if we move away from
> reference_counting, probably some additional complexity is worty,
> performance-wise, while waiting for C++0x, which is still a few years
> away (not to mention the actual implementation of the compiler bits).
> I'd appreciate your feedback about the basic_string applications, I'm
> not sure how *much* simulated move semantics we really want there.
>
>  
I did try poking around a bit with basic_string. Assuming that we aren't 
going to add move symantics compiler support (at least I'm not, I 
wouldn't know where to start) I think it's possible to make some 
progress, but perhaps not as much as we might like.

My understanding is that the problems from a non-reference counted 
basic_string fall into 2 main groups:

Statements like "string s = a + b + c + d;", secondly things like"Return 
s" involves copying s, and then immediatly destroying it.

The first of these I have a fix running for, which I believe is safe, 
which relies on the fact that if operator+ is defined as:

basic_string operator+(basic_string x, basic_string y) {..}

Then I can assume that at most one operation can be performed on the 
return value, and in particular if you add a boolean to basic_string 
which marks it as a return value, you can check that value and if it's 
true "steal" it's internal copy of the string.

The second type of problem (Return s), is exactly what complete move 
symantics is supposed to fix, and I don't believe is fixable without it...

Chris