Boost logo

Boost :

From: Herve Bronnimann (hervebronnimann_at_[hidden])
Date: 2006-11-29 12:25:48

On Wednesday, November 29, 2006, at 07:54AM, "Maarten Kronenburg" <M.Kronenburg_at_[hidden]> wrote:
>> The unsigned integer inherits from the signed one. While this does model
>>arithmetics correctly (a natural number is an integer, after all), it is the
>>unsigned integer that has richer functionality. It's clumsy and not
>>extensible to use inheritance in such a case.
>The normal and the unsigned integer have the same functionality, only the
>implementation is slightly different.

I've heard this often enough since the beginning of this discussion, and imho it's a major source of confusion and problems in the design. Google "Liskov Substitution Principle", "ISA Relationship" or other similar keywords, for more information. The famous example is Shape/Rectangle/Square (read for a good discussion).

So I have to say this loud and clear: a natural number <NOT> "is a" </NOT> integer. It is not, no more than a modular one is. Try subtracting 1 to 0, and you will not get the same behavior in either three types. This violates the LSP (Liskov Subst. Princ. mentioned above)

However, a const_unsigned_integer "IsA" const_integer, so long as you can't modify the value. Thus if you think of integer as a value semantic type, all is well in your relationships, but the presence of operator--, etc. dictates that unsigned_integer and integer should be unrelated classes. There is a hierarchy, equivalent to the famous example of Shape/Square/Rectangle, where (loosely speaking, and without syntactic rigor):
    class const_integer;
    class const_unsigned_integer : public const_integer; // a natural number is an integer, when talking about value semantics
    class integer : public const_integer;
    class unsigned_integer : public const_unsigned integer;
But note that the fourth side of the rectangle (unsigned_integer: public integer) is *not* provided.

The same goes even more drastically with modular_integer where some operations (operator<) don't make real sense.

I think this was mentioned back in June, perhaps not in such details, but I remember some people objecting to the inheritance back then. I think you should think about this seriously, Maarten, since imho it's a major flaw in your design, not taking any position on allocators or other issues. I don't have a particular opinion about how to fix the proposal, but I just want this forum to be at least aware of the issues.

Herve Bronnimann

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