Re: [boost] [mp_math] a multi precision signed integer library

From: Kevin Sopp (baraclese_at_[hidden])
Date: 2008-03-31 11:22:04

Hi Maarten,

On Sun, Mar 30, 2008 at 10:13 PM, Maarten Kronenburg
<M.Kronenburg_at_[hidden]> wrote:

>  Just for your info I designed another interface, see document N2143 on:

I knew about your document after I searched the internet for ideas on
how to design the interface of the mp_int class template.

>  http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/#mailing2007-01
>  The root question here seems to be: do you use runtime polymorphism (virtual
>  functions) or compile time polymorphism (templates). My argument is that as
>  this class is so close to the hardware, and performance is so important,
>  that runtime polymorphism will in this case provide the runtime flexibility
>  needed.

I never really understood why you chose this approach, it is really
different from the rest of the standard library. I understand that you
achieve interoperability with the other integer types but this could
be hardcoded once all integer types to be standardized are known. Also
I think that interoperability of the integer types is a minor concern
and as such should not govern the major design decision.

>  In your design the algorithms will probably end up in headers (just like the
>  STL), while my algorithms will end up in DLLs. In other words: my design
>  considers the allocator and the traits as implementation details (although
>  in my design it is possible to change the allocator dynamically), while your
>  design considers these as design parameters.

The traits parameter is totally implementation defined. I included it
because I wanted to give the user a way to customize some of the
internal workings of the class, usually in C libraries this is done
via macro definitions at compile time. Most users don't need to bother
but if you're a poweruser with very large calculations you have at
least a few knobs to finetune the internals. There was almost never a
question in my mind about the allocator parameter. After all it would
be strange not to have one for a class that will potentially allocate
a large amount of memory.

>  In other words: in my opinion an integer is not a container, so compile-time
>  flexibility is not needed, while runtime flexibility is needed for
>  combination in expressions of signed/unsigned/modular types and base tpye
>  pointers to derived type objects.

It does not look like a container but internally it is one. From a
Standard perspective it makes sense to give it an allocator parameter,
as this is what a user will expect.

Kevin