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.