minow@bolt.enet.dec.com (Martin Minow) (02/22/91)
In article <1991Feb20.205941.5105@iitmax.iit.edu>, soudan@iitmax.iit.edu (Bassel Soudan) asks about multiple inheritance under the Think Class Library. Since the compiler doesn't support multiple inheritance, you either need to write your own or take some other application-specific action. For example, CStaticText is a descendent of CPanorama, but adds some methods that are data-specific (SetTextHandle, for example) and others that are command-specific. Another useful method is to split the task into two (or more) separate classes that are linked together by reference instance variables, following the philosophy behind CScrollPane and CPanorama. For example, I wrote a ListManager analog that consisted of two classes, struct ListSelector : CList { CSelector *itsSelector; void IListSelector(void); void InstallSelector( CSelector *aSelector ); PRIVATE void AdjustSelector(void); void ChangeSelection( short aSelection ); void Add( CObject *anObject ); /* etc. */ } and struct ListPanorama : CSelector { long itsDoubleClickCmd; void IListPanorama( ... boring CSelector/CPanorama parameters ... ); void Draw(...); void HiliteItem(...); The CSelector contained the visual and command hierarchies, while the ListSelector contained the data. When objects are added or removed from the list, the method calls AdjustSelector which adjust the CPanorama's bounds. A slightly buggy source file was posted to the Think-C mailing list a few weeks ago. (send mail to think-c-request@ics.uci.edu to join). Good luck - hope this isn't too confusing. Martin.
snow@elbereth.rutgers.edu (Rob Hsu) (02/28/91)
soudan@iitmax.iit.edu (Bassel Soudan) writes: > I am trying to make an object in Think C 4.0 inherit from two > completely unrelated objects. To do this I need multiple inheritance. I can > figure out a way to hack multiple inheritance into my Class, but to do that I > need to know how does Symantec physically implement inheritance. Well, this may or may not help, but the last time I used Think C (more than 9 months ago), it came with the source files that implements its object oriented features. I was able to write a little function that returns the class of an object given the object itself. This source is all in assembler and sparingly documented, but you can actually figure out how everything works if you trace it through (and the debugger may help). Since then I've been hacking away at Unix and have not touched a Mac, so my memory is very rusty, but from what I can recall (probability of the following being correct is < 10%): --- BEGIN SPECULATION --- * class descriptions are implemented as global variables at offsets from A5. (You can actually use them as such, e.g. printf("%ld\n", CObject), or simply type CObject to the debugger. This would print out the address of the class record for CObject). I don't remember exactly what the format of the record is, but it contains at least a size, a bunch of pointers to methods of the class, and a pointer to its superclass. I vaguely remember that this superclass pointer is stored at the end of the class record. Inheritance is implemented by tracing this pointer. * the first two bytes of every object contains this offset, and therefore is an indicator of what class the object belongs. --- END SPECULATION --- The point is that you can figure it out yourself (provided you can read assembler code). Personally, I believe that the solution to your problem involves a re-design of your class hierarchy. Trying to hack out a solution to a problem of this magnitude is not very practical. ---------- Rob Hsu