Path: utzoo!attcan!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.lang.c++ Subject: Re: Shippable C++ Objects (RFC) Message-ID: Date: 21 Nov 89 18:40:33 GMT References: <98968@ti-csl.csc.ti.com> Sender: davidm@cimshop.UUCP Followup-To: comp.lang.c++ Organization: Consilium Inc., Mountain View, California. Lines: 65 In-reply-to: peterson@choctaw.csc.ti.com's message of 20 Nov 89 14:17:24 GMT In article <98968@ti-csl.csc.ti.com> peterson@choctaw.csc.ti.com (Bob Peterson) writes: In article cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >Based on previous discussions within these groups... You really should visit a library... I'm getting so much good information here ;-). But I am looking around... >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! Having attempted to do basically what you're saying with some people before coming to the conclusions in my previous article, I really don't see how the translation of any object into a shippable form could be encapsulated. There is just too much infomation that is within an object's definition to be passed to another class. The object itself has the best understanding of what it is composed of and what would be needed to reconstruct it from the information that it contains. What form would the "description" of an object take in order to pass it to the translation routines (I suspect the answer would be so complex that you would have wound up doing the most of the translation before you give anything to the translation routines). >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? I'm not sure about the life of the program, but the assumption for the symbol table is that the memory pointer would remain constant for the length of time it takes to build the shippable form of the object (the life of the symbol table). This, I think is a valid assumption. 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. My assumption was that each object would make the distinction about what of itself is shippable and what is not (therefore, designer responsibility). Howwever, the issue of object identity from the standpoint of working with the object after it is shipped and determining the difference between this last object shipped of class Foo and the previous object of class Foo was something I hadn't considered. I believe this is a question for the application designer, but I will look for the reference you gave. -- =================================================================== 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!"