Xref: utzoo comp.lang.c++:5574 comp.object:442 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!usc!samsung!rex!wuarchive!texbell!texsun!pollux!ti-csl!choctaw!peterson From: peterson@choctaw.csc.ti.com (Bob Peterson) Newsgroups: comp.lang.c++,comp.object Subject: Re: Shippable C++ Objects (RFC) Message-ID: <98968@ti-csl.csc.ti.com> Date: 20 Nov 89 14:17:24 GMT References: Sender: news@ti-csl.csc.ti.com Reply-To: peterson@choctaw.UUCP (Bob Peterson) Followup-To: comp.lang.c++ Organization: TI Computer Science Center, Dallas Lines: 61 In article cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: > >Based on previous discussions within these groups and some work I am currently >doing, I'd like to get some comments (please post) on the following ideas for >the shipment of C++ objects between processes (and, by implication, the >persistence of the object). > You really should visit a library and review the last few proceedings of relevant conferences and workshops, e.g., ACM OOPSLA Conferences since 1986, the OODB Workshops (one in '86 in California, and a second in '88 in Germany), and recent ACM SIGMOD Conferences. >2. Assume each class of objects has methods for building a shippable byte >array representation of the object and returning a pointer to that shippable >form. > >3. Assume each class of objects has methods for filling (or constructing) >itself from the shippable byte array representation made in (2). Seems to me that much of this code should be encapsulated in a translation class, with an object containing only a description of its type. The description is passed to the translation routines. Now a class implementor doesn't have to (again) write the same conversion routines, but simply write a type description. Even writing the type description could be automated! >7. Memory pointers are the special case. ... > Basically, the value of the memory pointer would be given to >the symbol table which would return a symbol for that memory pointer (either a >new one or the previous one). > This assumes that a memory address is constant over the life of the program. Is this a valid assumption? For example, a String class might reallocate storage if a string changes size, resulting in a different memory address for what, logically, is the same entity. Sending the same object twice should result in the same destination structure, without orphaned storage, regardless of reallocations that may happen. If a different memory address results in a different symbol the receiving end can't recognize that the original value is no longer needed. How do you prevent your transfer mechanism from shipping senseless values, i.e., values that make no sense to the receiving process? Examples might be a window object, or an I/O buffer, or a hash table maintained as redundant data purely for performance reasons. These and other identity issues are discussed in the paper, "Object Identity," by Khoshafian and Copeland in the _OOPSLA '86 Conference Proceeedings_ (published as the November 1986 (Volume 21, Number 11) issue of ACM SIGPLAN Notices), page 406. This article is a good discussion of the identity issue. >=================================================================== >David Masterson Consilium, Inc. >uunet!cimshop!davidm Mt. View, CA 94043 >=================================================================== >"If someone thinks they know what I said, then I didn't say it!" Bob Bob Peterson Compuserve: 70235,326 Expressway Site, Texas Instruments USENET: peterson@csc.ti.com North Building, P.O. Box 655474, MS238 (214) 995-6080 2nd Floor, Dallas, Texas, USA 75265 CSC Aisle C3