Adding moving to basic_string

Paolo Carlini pcarlini@suse.de
Tue May 17 13:10:00 GMT 2005


Jonathan Wakely wrote:

>>Therefore, optimizing operator+ is more important in the non-reference
>>counted case, for use in the very common a = b + c.
>>    
>>
>That case is optimal with ref-counted strings, but it couldn't take
>advantage of move anyway, since b is not a temporary.
>  
>
Right. We are talking about more than one operator+. Unfortunately we
cannot do much about the most common case, reference-counting wins, it
seems.

>The case I meant was a = b+c+d, which does a deep copy of the result of
>(b+c) and appends the contents of d to it.  The deep copy is
>sub-optimal.
>  
>
No, this is not true when reference-counting is in: operator+ over the
temporary
(b+c) and d, does *not* deep copy b+c! It does:

    basic_string<_CharT, _Traits, _Alloc> __str(__lhs);
    __str.append(__rhs);

and the copy constructor uses a shallow copy, similarly to operator=.

>Move semantics could make it as efficient as this (but less ugly):
>
>a = ((b+c) += d);
>
>Unfortunately, even with move semantics, that still wouldn't be as
>efficient as:
>
>a.reserve( b.size() + c.size() + d.size() );
>a = b;
>a += c;
>a += d;
>
>Since a re-alloc is likely to be needed and you can't call reserve on a
>temporary that doesn't exist yet.
>  
>
Humm, I have to think more about all those possibilities....

Thanks,
Paolo.



More information about the Libstdc++ mailing list