|
Boost : |
From: Howard Hinnant (hinnant_at_[hidden])
Date: 2002-02-05 19:40:36
On Tuesday, February 5, 2002, at 06:24 PM, Sean Parent wrote:
>> It is my wish that ultimately such a design could be merged into the
>> existing std::containers (and other containers as well for that
>> matter). In order for that to happen, the containers must be able to
>> detect at compile time if a class supports move semantics, then the
>> container could choose to use either move or copy semantics for things
>> such as insert.
>
> I don't think that is a plausible goal - the current containers assume
> copying semantics in a number of places (insert, push_back,
> construction).
> Even pop is designed with the notion that the user first retrieves a
> copy of
> the last element with back (if needed). Pop doesn't return the last
> element
> to avoid losing an element if an exception is thrown on the copy.
I think I misstated my goal. I'm hoping that containers will be able to
detect and use move semantics as an internal optimization, not effecting
the container's interface.
However, if after this internal optimization step, the container's
interface is augmented to move in to and out of the container, well
that's another interesting problem in its own right. But today I'm
looking only at optimizations internal to the interface.
The reason I can't just optimize my containers to my heart's content is
that we need universal agreement on move syntax and semantics before a
container can take advantage of move with user-defined objects.
-Howard
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk