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

Subject: Re: [boost] [xint] Fourth release, requesting preliminary review again
From: Jeffrey Lee Hellrung, Jr. (jhellrung_at_[hidden])
Date: 2010-06-10 10:15:38

On 6/10/2010 7:05 AM, Chad Nelson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 06/10/2010 08:15 AM, Giovanni Piero Deretta wrote:
>
>>> [...] 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.
>>
>> [...] Did you consider separating the big int data structure itself
>> from the big int algorithms, a la STL? This way anybody can roll
>> their own big int class according to their own need and you need to
>> provide only a default one, optimized for the common case. [...]
>
> I've tried making the algorithms independent by having them take an
> array and other information, but they need the freedom to reallocate as
> necessary (or I'd have to have two functions for each operation). That
> means passing them the allocator as well, at the very least. You end up

Why do you need to pass the allocator?  You cannot put the 
responsibility on the client code to provide a pointer to a free chunk 
of memory (whether heap/free store-allocated or stack-allocated) to 
write to?

The alternative, you say, is "I'd have to have two functions for each 
operations".  Can you elaborate?

> with four parameters for every integer you need to pass to a function
> (bool reference for positive/negative, size_t reference for length,
> size_t for max-length, and the magnitude array), plus making it a
> template because allocators aren't based on a standard class. Or wasting
> time packing and unpacking those same options to and from an
> intermediate structure of some kind. It was a lot faster and easier to
> pass it as the already-existing raw integer class, which already has
> that information plus allocation and other capabilities.

- Jeff