johnson@m.cs.uiuc.edu (09/06/90)
Reid Ellis says: >In a very general sense, there seem to be two methodologies when >writing object-oriented software: the SmallTalk model and the >not-SmallTalk model [NSM]. The dividing line between this model and >not-this-model is the existance of a unique base class, commonly >called 'Object' or 'TObject' or something similar. The alternative >with NSM is to have a number of non-unique base classes. >The tradeoffs involve the overhead of creating a new [small] >object which conceptually has no ancestors and the ability to use >this object. In the SmallTalk model you can send this object any >of a number of common messages, whereas this is not possible with >the NSM model. The difference between Smalltalk and C++ is that in Smalltalk you can send an object any number of common message, but it is NOT that there is a common superclass. The reason that Smalltalk lets you send any message to any object has nothing to do with its class hierarchy, but is simply that it is not statically type-checked and decides at run-time whether an object understands a message or not. It is possible to type-check Smalltalk (i.e. my group has built a type-checker for Smalltalk, not that anybody else in the world does it). However, a type in Smalltalk is quite different from a type in C++. A Smalltalk type is a set of messages that the object understands, but it doesn't say anything about where the methods were defined, whether it was inherited from a superclass or defined in the object's class directly. If you want to ensure in C++ that a few operations can defined by a set of classes then you have to give them a common superclass. However, this is just because of the type-checking rules of C++, and it will not necessarily carry over to other object-oriented languages like Smalltalk. >There are some caveats here, however. If the base Object only >consists of methods/messages with no data, it is conceivable that >its representation on the stack would be very small [type >information] since methods may not really be instantiated for every >object. As a matter of fact, class Object in Smalltalk does not define any data, so it is very lightweight. On the other hand, the *interpreter* ensures that each object has data, in particular a class pointer (like a v-table pointer), some fields for the garbage collector to use, and a "hash" value. I believe that in a good C++ design for a large system, most classes will have a common superclass. Although it is true that a common superclass adds overhead (mostly space overhead), most classes do not have enough objects that it makes much difference. In Choices, an operating system framework written in C++, probably 80 or 90% of the classes have a common superclass. Many of the remaining classes represent hardware features like page tables and have no virtual functions (and hence, no v-table). Some of the classes have no base class for reasons of efficiency, as mentioned above. The public, widely used class usually have the common superclass, while most of the classes without the common superclass are private. One of the main advantages of C++ is that, with work, you can have both elegance and efficiency. Please don't avoid elegance because it might be inefficient. Until you have some experience (which usually means until you have built the first version) it is very hard to tell which parts of a system are the bottleneck. Ralph Johnson -- University of Illinois at Urbana-Champaign