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

Subject: Re: [boost] New Boost.XInt Library, request preliminary review
From: Jeffrey Hellrung (jhellrung_at_[hidden])
Date: 2010-03-27 22:21:58

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