Chad Nelson wrote:
Right, *containers* (not compilers) must detect that move emulation layer. So COW does have an additional advantage: better performance with non-move-aware containers.
Yes, exactly. I'm not sure what's involved with making a container move-aware, but I'm fairly certain that the STL's containers aren't at present. I don't know whether the Boost.Move library will suffer from the same limitation.
A suggestion (perhaps not a good one): replace the thread-safe implementation of xint::integer with a move-aware one, and allow either to be chosen via preprocessor defines.
If Boost.Move doesn't have the limitation mentioned above, then I'll probably get rid of the copy-on-write stuff completely. It wouldn't have any advantage that I can think of, at least for the moment.
Within the (proposed) Boost.Move directory (but, I believe, submitted for separate review) are a full suite of move-aware STL containers. The code, I believe, is adapted from an existing STL implementation. So such move-aware containers, even without the presence of rvalue references, are readily available. However, I realize now my comment concerning move-aware containers was probably misplaced. I think the performance of xint::integer-valued containers should be only a very minor concern. Otherwise, perhaps we should discuss how to improve the performance a std::vector< std::vector<T> > container by using COW std::vector's. Oh wait, we have something better: (emulated) rvalue references ;) So for the time being, at least for the thread-safe version (which I guess could just be called the "move-aware" version, if you still end up with a COW version), I think you should use a custom implementation of emulated rvalue references (perhaps incompatible with Boost.Move, if you choose; I believe Boost.Thread may have something like this already, so it's not unheard of) so that you at least get the performance of moving *within* your library. The documentation and source for Boost.Move, plus referencing past discussions on this list, should give you enough information to understand the machinery. It doesn't require much code at all. Since this will be an implementation detail, it should be a simple matter, from there, to convert to using boost::rv<T>, if necessary and when appropriate. Some boosters will probably dislike having "another" move-emulation facility added to boost, but I think it's reasonable until a single move-emulation facility is made official. - Jeff