-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/09/2010 03:23 PM, DE wrote:
congrats with the new release! great job indeed!
Thanks!
i ran through the docs and partly through the sources and have something to say
is_odd and is_even is_a_good_decision_indeed in general i like what the interface looks like very much
Then you'll be happy to know that I've pretty much managed to keep it for the fifth release. :-)
so far i have a question about fixed_integer personally my intention was that fixed integers do not allocate memory on the heap but do everything completely on the stack
Unfortunately I don't see a way to safely and automatically provide entirely stack-based integers yet.
but now it's look like i need to do the following to achieve a fixed size int:
template<size_t size> class my_stack_allocator {/*...*/};
typedef xint::fixed_integer<512, my_stack_allocator<512> > int512;
in my opinion this is redudant since a the size of a given fixed integer is known in advance (at compile time) and it is intended to NOT allocate on the heap (as i understand it) and even not supposed to use an allocator
A stack-based integer's magnitude would always have to be stored directly adjacent to the integer itself on the stack, or risk having one deallocated before the other. That means no sharing of memory (even temporarily) for integers with identical magnitudes, and no moving magnitudes around by pointer-swapping -- every time you copy an integer for any reason, you'd have to copy each and every byte of the magnitude along with it. Swapping two 512-bit integers, just as an example, would mean three copies of 64+ bytes each, rather than a simple pointer swap. I assume you wanted to use stack-based memory for speed, but due to the above, it would likely be slower than the equivalent heap-based integer. Especially with a good caching allocator. It would probably also require some modifications to the lower levels of the code, to disable all the pointer-swapping stuff that I've built in for speed. That makes it difficult to experiment with it at present. Once the library is finalized, we can play with it and see if we can find a way around that problem. - -- 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/ iEYEARECAAYFAkwQRJcACgkQp9x9jeZ9/wQG0ACg2cseDTQsxKUwxBI5i32eFTLi IBIAn170wepEThdAOyUTn2tcncAEMdmz =sq3F -----END PGP SIGNATURE-----