Hi Maarten, On Sun, Mar 30, 2008 at 10:13 PM, Maarten Kronenburg <M.Kronenburg@inter.nl.net> 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