From: Kevin Sopp (baraclese_at_[hidden])
Date: 2008-03-31 11:22:04
On Sun, Mar 30, 2008 at 10:13 PM, Maarten Kronenburg
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk