Re: [boost] [xint] Third release is ready, requesting preliminary review

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-----
Hash: SHA1

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.
- -- 
Chad Nelson
Oak Circle Software, Inc.
*
*
*
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkve+wQACgkQp9x9jeZ9/wTa8wCfRtxMQcZIiaBxXYuFo7zHUlRj
/ZcAnROOugWfMCNK7s/90ZigWWzTK1i5
=OtSD
-----END PGP SIGNATURE-----