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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk