Re: [boost] Google SoC 2007 Big Integer project

From: Marco (mrcekets_at_[hidden])
Date: 2007-03-24 12:41:40

On Sat, 24 Mar 2007 12:31:41 +0100, Kevin Sopp <baraclese_at_[hidden]>  
wrote:

>> do you mean that it's possible to use std::allocator methods in order to
>> grow allocated space without the need to initialize it again with old  
>> data
>> ?
>
> No, I meant that you can use the realloc() function throughout the
> library without having to worry about whether the user passed in an
> allocator with std::allocator interface or an allocator that supports
> realloc(). By specializing a struct on the allocator type, it will act
> as a proxy and you call the struct's realloc() in the library.
> If the user passes in std::allocator the proxy realloc() function will
> still do an alloc/copy/destroy.
>

Ok, now I understand what you meant.

>>
>> I don't know if checking for states doesn't matter compared to the
>> complexity of multi precision algorithms. It's possible, I should try.
>>
>> parametrization for infinity, NaN and exception it's ok;
>> anyway what I wanted to point out it's that in the case there is a
>> performance loss, managing infinity and undefined states, then it is
>> better to implement different classes and it's so even using template
>> parameters: for instance classes big_integer<WITH_INF> and
>> big_integer<WITHOUT_INF> ( WITH_INF = true, WITHOUT_INF = false, and  
>> I've omitted the other template parameters ) will exdend a common class  
>> in such a way to share as much as possible, but they will be two  
>> different
>> template specialization of <bool use_inf>.
>
> It sounds like this will make things more complex than necessary.

I agree with you

> I just looked at the GMP manual [http://gmplib.org/manual/] and it looks
> like they don't support infinities etc. in fact they don't handle
> division by zero either because "This lets a program handle arithmetic
> exceptions in these functions the same way as for normal C int
> arithmetic."
>

well, anyway even if a division by zero throws an exception, a program  
could handle it in two way: the classical one checking the denominator  
argument before passing it to the division operator, and the one offered  
by the library by sourrounding the division operation with a try/catch  
block; the two methods are not exclusive.

Marco

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/