Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!nsc!voder!decvax!roger From: roger@decvax.UUCP (Roger H. Scott) Newsgroups: comp.lang.c++ Subject: Re: Problems with Cfront v2 Message-ID: <5@espol.decvax.UUCP> Date: 20 Dec 89 21:56:15 GMT References: <959@sl10c.concurrent.co.uk> Reply-To: roger@procase.UUCP (Roger H. Scott) Organization: proCASE Corporation, Santa Clara, CA Lines: 38 In article <959@sl10c.concurrent.co.uk> asc@concurrent.co.uk (Andy Chittenden) writes: >We have recently purchased version 2 of C++ and have managed to >get it ported to our system V.2 UNIX system. >... >In addition, we would like to use virtual inheritence with v2. However, >we have hit upon a snag. In v 2.0, objects derived from virtual base >class objects contain pointers to the base class objects. Our objects >will be saved and retrieved from disk. Such persistent objects cannot >contain pointers, only relative addresses or offsets. We have a similar problem at PROCASE. Our system (as CASE system for C programs) is built on a persistent C++ object database. With a tolerable amount of grundge we know how to passivate and activate "simple" (1.2 and 2.0 with single inheritance) C++ objects. The mechanisms used to implement MI in AT&T's 2.0 are *much* more difficult to passivate and activate - so much so that we quickly decided that we could not use MI in our work either. While this is a significant issue for us, it is far from the most important reason for our avoiding MI - the outrageous cost in both space and time. I am preparing a scathing indictment of AT&T's MI implementation for publication in this news group sometime soon. Just to whet your appetites, see if you can guess how big a single instance of class Der is as a function of , below: // all are abstract classes - no data members whatsoever struct Base { virtual void f(); }; struct Der1 : virtual public Base { }; struct Der2 : virtual public Der1 { }; ... struct Der : virtual public Der { };