Boost logo

Boost :

Subject: Re: [boost] [xint] Fourth release, requesting preliminary review again
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2010-06-10 11:58:40


On Thu, Jun 10, 2010 at 3:39 PM, Chad Nelson
<chad.thecomfychair_at_[hidden]> wrote:
>
> On 06/10/2010 10:15 AM, Jeffrey Lee Hellrung, Jr. wrote:
>
>>> 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?
>
> I could, but I don't see the point. See below.
>
>> 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: 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? 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.

-- 
gpd

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk