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