Subject: Re: [boost] [xint] Third release is ready, requesting preliminary review
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-05-03 12:34:12
-----BEGIN PGP SIGNED MESSAGE-----
On 05/03/2010 10:54 AM, Jeffrey Lee Hellrung, Jr. wrote:
>> In addition no information must be stored on base integer that
>> concerns fixed_integer. This is a bad design option, IMHO.
> My "HO" also is that the memory management should be separated from
> the arithmetic algorithms.
For the most part, it is.
> Whether the integer is a fixed_integer or not is compile-time
> information, so I don't think you should be keeping runtime
> information to mirror that.
It's needed for the memory management code.
> It sounds like it was your intent for base_integer to provide the
> implementation of the "core" arithmetic algorithms.
Close. base_integer handles the memory management; the free functions
handle the algorithms. The separation isn't perfect yet though.
> I would suggest moving the memory management up (or down, depending
> on how you view things) to the derived classes. How feasible is that?
> You can use CRTP to get access to the derived class's members.
It's not really feasible to push it to the derived classes, since it
would involve a lot of duplicate code. The memory management is almost
completely identical between all of the integer types, so it makes more
sense to have it in a base class.
However, as I mentioned yesterday, I've found a need to separate the
memory management functions from the base class anyway. I plan to move
them into an intermediary class, something that inherits from
base_integer, and that all the derived classes inherit from.
> This probably won't affect the interface or performance any,
> however, so it's much more an implementation detail than COW. It's
> still bothering me that you're finding moving to be so much slower
> than COW :/ We should try to get to the bottom of this. I'll find
> some time today to examine the code.
I may have identified the reason that it's slower, and as you suspected,
it's code that I'd designed while thinking of copy-on-write. I'll
experiment with that today. If I can get the move implementation at
least as fast as the copy-on-write one, I'll happily remove copy-on-write.
Oak Circle Software, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----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