From: Maarten Kronenburg (M.Kronenburg_at_[hidden])
Date: 2006-05-26 07:58:17
Thanks for your comments.
With respect to inheritance I take the
Inheritance is something that is part of C++
and therefore users are always allowed to
derive from any class.
There is no way of explaining to a user that
for some technical reason (like the destructor
is not virtual), it is not allowed to derive from
And as mentioned in my reply to Gerhard,
every unsigned integer is an integer, so there
is every reason to choose this design.
"Bronek Kozicki" <brok_at_[hidden]> wrote in message
> Bronek Kozicki <brok_at_[hidden]> wrote:
> > Gerhard Wesp <gwesp_at_[hidden]> wrote:
> >> This would violate Item 32 in Effective C++, 3rd ed. by Scott Meyers:
> >> Make sure public inheritance models "is-a". I suggest deriving from
> >> integer be disallowed in the TR2 proposal.
> > I second that. If the class has not been designed from the ground up
> > (virtual functions, interface classes etc.) to allow sensible
> > inheritance, it should be disallowed.
> oops, I used too strong word here. I only hope than next sentence ...
> > I think that all STL classes
> > follow that rule.
> ... might explain what I actually meant. But let mi clarify: if class
> does not make proper use of inheritance, it should not mislead its user
> that it been designed to do so. Virtual destructor is kind of
> declaration "this class is designed to be inherited from", but it does
> NOT make it "good OOP-player". It the property of the design that can be
> recognized by use of interfaces and virtual functions and not virtual
> destructor alone. If integer type does not employ this kind of design,
> it should not mislead its users by providing virtual destructor. Making
> destructor public and nonvirtual does not make inheritance "illegal", it
> just declares that class had not been designed to be used as a base
> class. And this is how in my opinion integer class is designed and I
> like this design. Virtual destructor would only add confusion - because
> it would raise questions about contract between base class and its
> children (there is no contract in the project, thus inheritance does
> not make sense).
> Unsubscribe & other changes: