-----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-----