Re: [boost] [xint] Fourth release, requesting preliminary review again

Subject: Re: [boost] [xint] Fourth release, requesting preliminary review again
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-06-09 21:49:15

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