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

From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-03-31 13:14:15

On Mon, Mar 31, 2008 at 6:39 PM, Maarten Kronenburg
<M.Kronenburg_at_[hidden]> wrote:
>
>  "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.

You can easily make two multi precision integers or policies using
different allocators interoperate:

 Int<signed, my_alloc> x = -5;
 Int<unsigned, your_alloc> y = 10;
 x -= y;
 y -= x;

This can be almost trivially made to work, I think.

In case of x + y, you just need to decide which combination of rhs and
lhs policies to use.

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

It is easy to add runtime polymorphism to static polymorphic desings.
It is impossible to do it the other way.

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

If you use a scoped allocator (a-la alloca) as a template parameter, a
decent compiler could completely optimize it away. It is very hard
(although not impossible) to do the same if you have a runtime
indirection.

-- 
gpd