It's v7-> mainline merge time!

chris jefferson caj@cs.york.ac.uk
Sun Nov 27 12:59:00 GMT 2005


Gabriel Dos Reis wrote:
> Paolo Carlini <pcarlini@suse.de> writes:
>
>
> | -2- Simulated move semantics, basically as-is in the branch. The
> | entire merging work can be split in the infrastructural bits (e.g.,
> | moveable.h, slt_construct.h, stl_uninitialized.h, testsuite),
> | algorithms, trivial containers, vector and deque, testcases  as we
> | go. I'm pretty sure the work is safe from the binary-compatibility
> | point of view (or can be made so with minor tweaks): in the most
> | complex case, vector and deque, in a nutshell, functions like, e.g.,
> | _M_insert_aux, _M_fill_insert, _M_range_insert, will use __move and
> | become faster when moveable types are detected.
>
> I'm deeply reserved about that experiment going to mainline.
>
>   
I'm not going to try to (and of course couldn't) force this code to be 
accepted. Let me try to put it in another light which may make it less 
scary!

This code actually started, and was almost entirely written, independent 
of move semantics / rvalue references. The aim of the code was simply to 
provide a way of using "swap" on all complex objects, and simple 
assignment on all other objects. After a lot of fiddling, it turned out 
the only way to do this without allocating of empty memory and 
constructing into it was to add new constructors. Therefore, a better 
method to consider the current move semantics might be "allowing swaps 
instead of assignment, which happens to require adding some construtors".

When I found out about move semantics / rvalue references (which have 
much bigger aims than I did), I altered my underlying structures / code 
so that it looks more like those, so if/when they are implemented those 
will be easier to map to. In particular, I haven't made any attempt to 
support "advanced" features of rvalue references, in particular "my" 
rvalue references don't even automatically decay back to normal 
references, which would be easy to do, as I didn't want them "escaping" 
around the place.

This would of course all become more clear-cut if rvalue references were 
added to the compiler. I'm not sure how likely that is, and I can 
imagine there could be a number of complicated issues there.

Chris




More information about the Libstdc++ mailing list