2011/8/16 Ion GaztaƱaga <igaztanaga@gmail.com>: [snip]
You always need the include, just like you needed it when MyMovable was copyable, move is an optimization it does not offer type erasure.
Yeah I get that that. I probably wasn't clear, I only meant that no include was needed if instances were kept by (smart) pointer and not by value.
If you need to break dependencies, use pimpl idiom for all your members (Warning: I haven't compiled it):
[snip] So there is no really a way around it, is there? Either: 1) objects in container have to be kept by pointer to break dependency but then they have to be allocated on the heap so there is little or no benefit in making them movable (as smart pointer will provide necessary copy/move/ownership semantics) 2) whole container has to be pimpled so that hidden implementation may then take advantage of all move goodies like container emplacing I feel like 2nd option is the one that gives real benefits. Is that right? Also, I often write code like: class Widget { public: typedef std::vector<shared_ptr<MyMovable> > MyMovables; const MyMovables& movables() const; private: MyMovables movables_; } so that clients can later do: BOOST_FOREACH(MyMovable& m, indirect(widget->movables()) { // do something with m } how to design Widget's class API in similar way if MyMovables is hidden behind pimpl? I mean: class Widget { public: ??? movables() const // what return type here? private: class Internals; Internals* pimpl_; } or maybe an API is just broken altogether? PS. I just compiled such a code: //widget.hpp class Movable; // only forward declared class Widget { boost::container::vector<Movable> movables_; } and widget.cpp properly adds Movable instances by moving them to movable_. Why does this work? If this is normal then I have no problem at all ;) Best regards and thanks for such a great libraries, Simon