Re: [patch] : Adding move symantics to vector

[Paolo Carlini <pcarlini at suse dot de>]

Hi Chris,

finally I'm starting on your patch. A couple of initial comments, then
will apply it here, regtest on a couple of machines and send any
additional comments about the code itself and whatelse.

>Here is a patch which makes vector rvalref-aware, so it never performs
>unnessasary copies of things internally when it is shifting around things.
>  
>
Very cool!

>I haven't added any more of the user-visable changes (function which
>allow you to push_back an rvalref, etc), espically due to recent
>problems with the constructors.
>  
>
Agreed. Those are small nice additions that can be added later.

>The major final thing I haven't added (and the reason I've been quiet
>for a while) is that I've been having great problems implementing move
>semantics on stable_sort and stable_partition without either moveable
>types or trivial types (like int) being sub-optimal, or the code
>bloating. I hope to crack this soon :)
>  
>
Well, in my understanding, another interesting general improvement would
be making *deque* internally rvalref-aware. I see that probably it's
also not trivial. More or less than the stable_* algorithms? Your take?
As I see the issue, probably having deque done would improve the
consistency of the general framework.
(well, some sort of move-semantics improvement for __vstring would be
also cool, but in that case I'm "afraid" ;) that I have to work it out
myself, suggestions are definitely encouraged, of course!)

>I also now consider that all the "basic framework" and most of the speed
>improvement of templated-based rvalue references are present. However it
>looks like it might be too late now for 4.1?
>  
>
Yes, see also above. As I alredy told you, at this point my plan would
be adding to 4.1 only a version of the search_n improvements (and fixing
bugs!). Then, as soon as 4.1 branches, backport first the
simplifications to the algorithms (shuld be rather straightforward and
there are hopes that the very minor remaining code quality issues will
be addressed in the compiler in time for 4.2), then start on move
semantics. That seems to me a safe path.

>This patch has been bootstrapped on powerpc-apple-darwin8.2.0 and x86 linux.
>  
>
Honestly, I smile when I read this ;) In my opinion, when the library is
concerned, if one has really to choose much better spending CPU time in
regtesting than bootstrapping (I'm sure Jason once said bootstrapping is
often not necessary even when testing the C++ front-end changes).

Paolo.