From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2008-07-07 12:58:55
Joel de Guzman wrote:
> Hmm... well...
> a) How do you put a noncopyable object in a container?
- You construct directly the object within the container, which is
preferred, since optimal. As I said later in the thread, optional has
been using this technique for ages by taking an unary functor taking an
address. The right functor can then be generated by in_place<T>(args...)
(which is actually quite similar to "construct" in lambda/phoenix).
The technique used in C++0x containers (placement insert paper) is
different though, the insertion (insert/push_*) functions are replaced
(except insert, due to ambiguities, so the alternative version is called
"emplace") to take the args of the constructor directly. It's way less
compile-time efficient and generic, but supposedly it's easier to use.
(I personally fail to see how, v.push_back(in_place(args...)) isn't more
difficult than v.push_back(args...), and there would be no ambiguity).
- You move an already constructed object, which may be cheaper than
copying it or not. Most objects are movable though, which is not the
case for copying.
> b) How do you copy a container with noncopyable elements?
You do not. A container of copyable elements is copyable.
A container of movable elements is movable.
A container of non-movable elements may be movable or not.
> Fusion vector is based on stl vector. Even stl vector requires copy
> constructible types.
And that's a major defect of the STL.
I'm personally quite looking forward to the containers with move
semantics and placement insert that Ion Gaztanaga is working on (I hope
he still is).
> One possibility is to store your object in a smart pointer or
> wrap it in a reference wrapper.
A fairly high price to pay to work around an obvious defect IMO.
I know a few people that have been using zero-sized vectors but with
some capacity so that they could directly construct their objects in it.
An ugly hack, but at least it works as expected.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk