Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!elsie!nih-csl!keith From: keith@nih-csl.UUCP (keith gorlen) Newsgroups: comp.lang.c++ Subject: Re: Disk save/restore of derived class objects Message-ID: <264@nih-csl.UUCP> Date: Sat, 29-Aug-87 12:23:11 EDT Article-I.D.: nih-csl.264 Posted: Sat Aug 29 12:23:11 1987 Date-Received: Sat, 5-Sep-87 07:06:26 EDT References: <36ed1da2.c449@apollo.uucp> Organization: NIH-CSL, Bethesda, MD Lines: 62 Summary: See the OOPS Class Library storeOn()/readFrom() functions In article <36ed1da2.c449@apollo.uucp>, laporta@apollo.uucp (John X. Laporta) writes: > > Derived classes with virtual functions pose a problem for disk save and restore. > Standard software techniques allow easy transformation of memory objects into disk > objects, but the value of the _vptr member of derived classes in which virtual > functions are defined is program-specific in environments where the class library > is bound in with the program. This complicates save and restore considerably, since > a _vptr written by one program is invalid when read by another. > > One technique for solving this problem follows. ... [Technique that involves explicit manipulation of the _vptr member described] > Does anyone know a simpler or better solution? I think so. My Object-Oriented Program Support (OOPS) class library implements storeOn()/readFrom() functions similar to those of SmallTalk-80 for storing arbitrary data structures comprised of OOPS objects on an ostream and reconstituting them from an istream. As you correctly point out, one program's _vptr is, in general, invalid in another program's address space, and must therefore be converted into something portable. You are also correct in being concerned about a technique that relies on the specific implementation of virtual functions, since this will change if/when multiple inheritance is added to C++. (Bjarne has written a paper describing an implementation of this). The technique used by OOPS is described briefly in the chapter "C++ Under UNIX" which has just been published in *The UNIX Papers*, I have written a detailed description that will be published (eventually) in *Software -- Practice and Experience*, and the code is in the public domain, so I won't go into details here. Basically, when an OOPS object is stored, the name (in ASCII) of its class is stored along with the values of its member variables. Each OOPS class implements a constructor function that takes an istream and a pointer as arguments, reads the member variable values from the istream, and constructs an instance of its class at the specified address. Executing this constructor function in the context of the reading process does whatever is necessary to setup the virtual function binding in an implementation independent manner. The reading process must also be able to relate the name of the class of an object to be read to the appropriate constructor, which is handled in OOPS by an instance of class Dictionary that is setup by static constructors. At first you might think that storing the class name for each object would consume an excessive amount of space, but it need not be so bad because the class name can be stored just once for each class needed by a data structure, and all the instances of each class can share the same class name. To get a copy of the "guru-only" version of OOPS, just send me a letter on your company or university letterhead requesting the "Object-Oriented Program Support (OOPS) class library for C++" and a reel of 1/2" mag tape (a small reel will suffice). I'll return the tape with a copy of OOPS recorded on it in tar format at 1600 bpi, and I'll include a copy of the (incomplete) OOPS reference manual. Please include your uucp address in the letter. -- Keith Gorlen phone: (301) 496-5363 Building 12A, Room 2017 uucp: seismo!elsie!nih-csl!keith National Institutes of Health Bethesda, MD 20892