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?

Two possibilities:

- 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.