Boost logo

Boost :

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at