Adding moving to basic_string

[Paolo Carlini]

chris jefferson wrote:

> 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.

Cool. We have definitely to go ahead in this direction.

But, I guess, at least for benchmarking purposes, you would find useful
a basic non-reference counted basic class of v7 basic_string (+ short
string optimization)... As soon as I'm done with some ongoing work, I
will add one that I have here, basically working, still rough but can
serve the immediate needs, I think.

> 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...

I agree. Let's no try to do too much, in this area, anyway: some
definitely useful bits, with an approach easily upgradeable to the
"real" move semantics. Basically the same, very succesful, in my opinion
;) strategy that we are using for algorithms and containers.

Paolo.