-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/10/2010 11:58 AM, Giovanni Piero Deretta wrote:
The alternative, you say, is "I'd have to have two functions for each operations". Can you elaborate?
One to calculate how much memory would be needed, and (probably) allocate it -- the calculation is different for every operation. The other to do the actual calculation.
I do not buy this:
Too bad, it's on sale and you're missing a really great deal. ;-)
as an example, std::copy does not need to know the size of the output sequence nor need to know how to grow it (one can for example use back_inserter for automatic growth). Couldn't xint use a similar strategy?
std::copy doesn't need to know how to grow the output sequence, but it *does* need to be passed the back_inserter, which needs to know how to grow it. What's the difference between having a calculation function that takes the components of raw integers and a class to reallocate them, and simply sending in the raw integer objects that already have all the components and know how to reallocate themselves?
For an heap allocated big int the ouptut iterator can take care of any reallocation, while for a fixed point big int, in case of overflow, one could chose between UB, assert or throw. In principle there is no reason for algorithms to deal with memory allocation details.
Any algorithm that has to modify the size of a buffer has to deal with memory allocation, one way or another, at some level. The more indirect you make it, the harder it is to get speed out of it. I'm trying to make the fastest pure-C++ large-integer implementation I can. - -- 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/ iEYEARECAAYFAkwRGMEACgkQp9x9jeZ9/wQHVwCfY8jCptphscioMWO2ooAcGPu0 eNkAn0EheZAZ+qBoFs8vkutlbllDxfza =SzGM -----END PGP SIGNATURE-----