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-04-30 18:10:07

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/30/2010 05:02 PM, DE wrote:

>> I'm happy to announce that the third release of the Extended Integer
>> library is ready, in both the sandbox and the Vault. [...]
> 
> well i tried to lay my emotions aside and inspect the lib itself
> 
> i must say however that the docs are very clear and tell about the
> library almost all i want to know
> there are wise words there indeed (e.g. on rationale page)

:-)

> so i think that the design of the library is _perfect_ (yeah, yeah, i
> know that there is always room for improvements...)
> beside other things i understand why you did things this way and not
> the other way

I tried to convey them.

> however so far i have a suggestion about fixed_integer
> for me it is counter intuitive that a fixed_integer<N> allocates
> memory on the heap rather than on the stack [...]

That was a tough decision. I started out with it on the heap, but
there's no way to use the more-efficient swap(), operator=, or copy/move
constructors that way. The best choice came down to which set of
operations happens more commonly: swapping and assignment or creating a
new object. I have no way of objectively measuring that for other
people's code, but for my own, swapping and assignment edge out object
creation, slightly.

> classes are not polymorphic and slicing is not intended
> in other words the most derived class is responsible for memory
> management so if a necessity appears to allocate different storage it
> can be correctly freed on destruction like
> 
>   ~fixed_integer()
>   {
>     if (this->data && this->data!=this->fixed_data)
>       deallocate(data);
>   }

Yes, that's the design I used for the "quick digits" in the earlier
version of the library.

> this way you don't need to rewrite everything and you get rid of
> costly allocation
> in case you say that data allocated on the heap makes implicit sharing
> possible i'd say that copying of reasonable size fixed ints beats
> allocations in the end

Since the data for a fixed_integer will always be the same size, the
implementation could re-use older allocations instead of deallocating
them and allocating new ones. I can see a fairly easy way to do that,
and give the user control over what's being held if he wants it. Would
that address your concern?

> i hope i got everything right in the implementation and all this
> doesn't sound like nonsense
> anyway i hope you got the main idea

I think I did. :-)

> oh and one more suggestion
> when you define a variable that is not meant to be modified declare it
> const
> it immediately provides information to a reader and also compiler
> ensures your intention

Did I miss one? Other than possibly the zerodata stuff, I can't think of
any that should be const but aren't. Hm, maybe some POD types in the
internals...?
- -- 
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/

iEYEARECAAYFAkvbVT4ACgkQp9x9jeZ9/wR+HACg6wky+AGMlYfQvHsy9mrHf1Ii
o8AAoINaoU31GWBlAIQNKiPpBwZJlKy8
=H72T
-----END PGP SIGNATURE-----