Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.object Subject: Re: Examples of Multiple Inheritance? Message-ID: Date: 30 Dec 90 03:33:05 GMT References: <47353@apple.Apple.COM> <1990Dec17.223306.25756@Neon.Stanford.EDU> <1990Dec22.220016.19624@Neon.Stanford.EDU> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 70 Nntp-Posting-Host: teachk In-reply-to: craig@Neon.Stanford.EDU's message of 22 Dec 90 22:00:16 GMT On 22 Dec 90 22:00:16 GMT, craig@Neon.Stanford.EDU (Craig D. Chambers) said: craig> In article craig> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: pcg> On 17 Dec 90 22:33:06 GMT, craig@Neon.Stanford.EDU (Craig D. pcg> Chambers) said: craig> If you're concerned about space overheads of MI, other craig> implementations of MI than the one in C++ 2.0+ have low space craig> overheads, comparable to pre-MI C++ implementations (i.e. a word craig> or two extra per object). pcg> This is not strictly true: the space overhead of MI in C++ 2.x when pcg> implemented without code thunks is not in the object, but in pcg> pointers to virtual member functions for the object's class. Also, pcg> multiple virtual inheritance also requires N-1 extra pointer words pcg> in the object for each suboject inherited virtually inherited N pcg> times. craig> I was talking about per-object space overhead, i.e. extra space craig> in the representation of an object over the representation of its craig> components. I am not aware of any case (except virtual MI as written above) where inheritance in C++ whether multiple or not requires a per object space overhead. There is overhead connected to virtual functions, not to inheritance. craig> Also, all class-based languages I know of embed the craig> representation of their superclasses into the subclass, so craig> there's no overhead here (sharing of the superclass is not an craig> issue). C++, again excepted for virtual inheritance, does the same. craig> The fact still remains, then, ignoring the "overhead" of pointers craig> and dynamically-bound message passing, that other implementations craig> typically use an extra word or two of space *per object*, craig> independent of whether MI is used or even a feature of the craig> language. MI C++, on the other hand, uses more space *per craig> object*. I cannot understand you here. Did you mean to write that MI C++ uses more space *per pointer* or *per class*? As you said above, if we ignore the costs of virtual functions/dynamic binding, MI C++ has absolutely no extra space overhead per object over SI C++. Indeed, if virtual functions are not defined, there is zero per object overhead. Maybe you refer to the fact that in C++ there is a separate vtable and vtable pointer for each class type, and they are not merged with inheritance, as this would require different offsets. Well, again this is purely an effect of a common _implementation_ of _virtual functions_, and of the general requirement that in C++ any component, whether inherited or not, of an object, can be pointed to and used on its own. There are other languages that have this property, and they require special trickery. For example I have read an article in which negative member offsets were used to get around many cases where otherwise offsets would have been jumbled around. It is conceivable that virtual functions in C++ could be implemented too in quite different ways from how they are implemented in cfront. It is in no way implied by how MI is defined in C++. It is a consequence of how virtual functions are realized. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk