Re: [boost] Yet another bignum type

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2006-12-01 14:17:08

simon.sebright_at_[hidden] wrote:
> I seem to have joined the thread in the middle, sorry if I am repeating
> something already said...
> 
> I guess I am reinforcing what I have been picking up on this thread.
> I.e. that behaviour of something can be disconnected from what it is (a
> square is a rectangle in geometry, but the behaviour of a square object
> does not meet the contract of a rectangle object).  

Right. In particular, a derived class should always either extend or 
just implement its base.

> In the computer
> world, inheritance is a very strong relationship, and needs to be
> considered carefully, taking into account the dynamic nature of the
> instances.

I fully agree. However, the "secretary IsA employee case" is not bad 
design per se (as the integer case sure is). 
As you correctly pointed out there are cases (considering what we're
actually trying to model) where it's better to do it differently, still.

> The above separation of employee/role is a bit of a strategy pattern, I
> think.  Maybe it could help the integer issue, such that the various
> required integer classes could hook up to sets of behaviour, some in
> common, some not.  

C++ is very powerful when it comes to code reuse in an implementation.
We might as well just put the common stuff into functions - and I don't
think we should be too concerned with the implementation when talking 
about the interface.

> Traits might be able to contribute too.

Right. The only reason to use polymorphism to implement the Strategy 
pattern in C++ that I can currently think of is modularization (hiding
the source, reducing build dependencies, ...). 

The easiest way to fix the design of the proposed library is probably 
to have two unrelated classes for signed and unsigned and an implicit 
widening (unsigned->int) conversion sequence and an explicit narrowing 
(int->unsigned) one.

Allocator and modulation should be passed in via template parameters 
taking an optional Allocator value in the ctor (Allocators are a good 
example implementing the Strategy pattern with templates, BTW).

The Allocator should be STL compatible (and it might be a good idea to 
add a 'reallocate' member function to that concept, anyway - IIRC, there
are STL implementation that already have such a beast). 

The Modulus parameter would be the type of a Singleton who manages the
initialization of the value and exposes it through a static function.

The signed integer would allow signed and unsigned modulus.
The unsigned integer would only allow an unsigned integer type for the 
modulus.

> Anyway, what about the fact that it is not a good idea to have multiple
> concrete classes in a hierarchy?  That would debunk one int class
> deriving from another.

I'm not sure it's wise to say so rigorously. You brought up the Strategy
pattern, so let's consider a fully implemented default Strategy to inherit 
from. It isn't all that bad of an idea, is it?

Regards,
Tobias