Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk