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

From: Maarten Kronenburg (M.Kronenburg_at_[hidden])
Date: 2008-03-31 12:39:44

"Kevin Sopp"  wrote in message > Hi Maarten,
>
> On Sun, Mar 30, 2008 at 10:13 PM, Maarten Kronenburg
>  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.
>
Interoperability is a major concern, because it is also available for the
base type ints:
int x = -5;
unsigned int y = 10;
x -= y;
y -= x;
etc.
The STL is made with templates, and rightly so, because containers have
template parameters (e.g. what type they should contain). But this does not
mean that other designs should be "templatized". Sometimes programmers need
runtime polymorphism to achieve runtime flexibility, and in my opinion the
integer class is an example.

> >  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 my opinion implementation parameters should be kept out of the interface.
I agree about the allocator, this is why in my design I have added an
allocator, only it is set at runtime.

>
> >  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.
>

In this view everything is internally a container. In my view a container is
something that can contain anything (the template type parameter), while an
integer can only contain contiguous bits.
Yes I agree that the STL uses allocator template parameters, but what if I
want to concatenate two standard strings with different allocators? In my
design adding two integers with different allocators is possible because
they are derived. Whether signed, unsigned, modular, allocated etc., because
they are derived from the same base class (in this case integer), they can
be mixed in expressions, just like the base type ints.
Perhaps you think this interoperability is not so important, but what if
large user groups use this and suddenly they require this? In a way this is
the same issue as with the impossibility of derivation from the STL string
(no virtual destructor). In the case of this integer class I don't think we
can ignore this.
Regards, Maarten.