Boost logo

Boost :

Subject: Re: [boost] [xint] Fourth release, requesting preliminary review again
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-06-10 12:54:30

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.
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


Boost list run by bdawes at, gregod at, cpdaniel at, john at