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