Chad Nelson wrote:
As described on the rationale page of the documentation, the primary reason I'm using copy-on-write is that move semantics aren't widely available yet. Portability is one of my primary goals, and while I've seen references to a move-semantics-emulator in Boost, I've also seen suggestions that it relies on the compiler to somehow recognize it. That doesn't sound fully portable to me. Have you looked at the (proposed) Boost.Move library by Ion (available from the sandbox)?
It does a pretty good job of emulating move semantics for compilers that lack rvalue references.
No, I wasn't aware of its existence. I haven't seen it mentioned on this list in the last couple weeks, is it under review for official acceptance?
AFAIK, it is in the review queue.
If not, no offense, but I can't use it. I'll be happy to do so when it's an official part of the Boost library though.
I understand your hesitation. I am currently using it myself, but only as far as being compatible with the semantics of boost::rv<T>& and const boost::rv<T>& (which amounts to all of about a half dozen lines of code from move.hpp). The rest of the framework I'm either reimplementing, refining, or wrapping, since the interface hasn't been finalized, but everything is/will be still compatible with other code that recognizes boost::rv<T>. I think the advantages that move emulation has over copy-on-write (better performance, simpler implementation, thread safety) outweigh its disadvantages (the framework built around boost::rv<T> is still somewhat experimental), so I would urge you to take a look at it in the near future.
Not sure what you're referring to by "suggestions that it relies on the compiler to somehow recognize it"...can you elaborate?
I finally tracked down the reference. From the "Thread Management" documentation page of Boost.Thread:
- ------------------------8<----------------------- Objects of type boost::thread are movable, however, so they can be stored in move-aware containers, and returned from functions. [...]
[Note: On compilers that support rvalue references, boost::thread provides a proper move constructor and move-assignment operator, and therefore meets the C++0x MoveConstructible and MoveAssignable concepts. With such compilers, boost::thread can therefore be used with containers that support those concepts.
For other compilers, move support is provided with a move emulation layer, so containers must explicitly detect that move emulation layer. See <boost/thread/detail/move.hpp> for details.] - ------------------------8<-----------------------
I misremembered it slightly, but the general argument still stands: move semantics aren't widely available yet, so the copy-on-write behavior of XInt is necessary for now. - -- Chad Nelson Oak Circle Software, Inc.
Right, *containers* (not compilers) must detect that move emulation layer. So COW does have an additional advantage: better performance with non-move-aware containers. 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. The choice of using COW or move emulation might be regarded more as an implementation issue, but (I'm guessing) will probably be brought up again during review. I will try to take a look at the rest of the library shortly. - Jeff