From: Bronek Kozicki (brok_at_[hidden])
Date: 2006-05-26 07:33:35
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).