|
Boost : |
Subject: Re: [boost] New Boost.XInt Library, request preliminary review
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-03-27 21:07:55
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>>> Have you looked at the (proposed) Boost.Move library by Ion (available
>>> from the sandbox)? [...]
>>
>> 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.
Ah, excellent. As soon as it's approved, I'll be happy to take advantage
of it.
> I understand your hesitation. [...] 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.
Certainly. It should allow XInt to run at copy-on-write speeds, even in
thread-safe mode -- a major improvement, and one that I'd jump at.
>>> 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: [...]
>
> 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.
> 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 think I can defend the decision if it is. :-)
> I will try to take a look at the rest of the library shortly.
Thanks. I appreciate the feedback.
- --
Chad Nelson
Oak Circle Software, Inc.
*
*
*
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuuq+sACgkQp9x9jeZ9/wQrbwCgySb5iD38QmEldkYWePd4AS78
ROYAoKfbtVIJHZwJ8VjBNHS89gtIPKZe
=lqiF
-----END PGP SIGNATURE-----
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk