Bronek, Thanks for your comments. With respect to inheritance I take the opposite view: 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 a class. And as mentioned in my reply to Gerhard, every unsigned integer is an integer, so there is every reason to choose this design. Regards, Maarten. "Bronek Kozicki" <brok@rubikon.pl> wrote in message news:000d01c680b8$3b311cd0$4904a8c0@actix.com...
Bronek Kozicki <brok@rubikon.pl> wrote:
Gerhard Wesp <gwesp@google.com> 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).
B.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost