Re: [boost] New Boost.XInt Library, request preliminary review

Subject: Re: [boost] New Boost.XInt Library, request preliminary review
From: Jeffrey Lee Hellrung, Jr. (jhellrung_at_[hidden])
Date: 2010-03-27 13:38:27

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