davidm@uunet.UU.NET (David S. Masterson) (01/09/91)
I'm looking for an interpretation of what is said in the ARM. In section 12.8, it talks about copy constructors and generating bitwise copies and/or bitwise assignments and: "The programmer may define one or both of these. If not defined by the programmer, they will be defined as memberwise assignment and memberwise initialization of the members of X, respectively." How is memberwise assignment or initialization meant to handle virtual functions and the hidden virtual function table pointer? Is the Vtabptr left alone in this? The reason I ask this has to do with transmitting of objects from one process to another. Assuming that type of the object is known after transmission, it should be possible to cast the transmission buffer to that type and copy construct a true object of that type using the buffer as input. Does this make sense with respect to section 12.8 in the ARM? -- ==================================================================== David Masterson Consilium, Inc. (415) 691-6311 640 Clyde Ct. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"
jbuck@galileo.berkeley.edu (Joe Buck) (01/09/91)
In article <CIMSHOP!DAVIDM.91Jan8174302@uunet.UU.NET>, cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: |> I'm looking for an interpretation of what is said in the ARM. In section |> 12.8, it talks about copy constructors and generating bitwise copies and/or |> bitwise assignments and: |> |> "The programmer may define one or both of these. If not defined |> by the programmer, they will be defined as memberwise assignment |> and memberwise initialization of the members of X, respectively." |> |> How is memberwise assignment or initialization meant to handle virtual |> functions and the hidden virtual function table pointer? Is the Vtabptr left |> alone in this? That is implementation-specific. An implementation doesn't even have to have a "Vtabptr"; it could use a different method. In practice, any constructor for class Foo simply sets the virtual function table pointer to point to the table for class Foo; the copy constructor does not copy it. |> The reason I ask this has to do with transmitting of objects from one process |> to another. Assuming that type of the object is known after transmission, it |> should be possible to cast the transmission buffer to that type and copy |> construct a true object of that type using the buffer as input. Does this |> make sense with respect to section 12.8 in the ARM? You're completely on your own; the ARM doesn't deal with any of the issues you will encounter here. I recommend not depending on any details of how your compiler represents virtual function tables and pointers to them, or your code may break on a subsequent release of the compiler. The details depend on your design constraints. Will you pass the data across a network? If so, will you need to support multiple architectures? Then your data may need to be byte-swapped and who knows what else. People have solved this problem by using standard external data representations; you'll want classes that isolate the responsibility for doing this so all the ugliness is in one place. The packet you send will need to have a data field that identifies the type in some way, and you'll need to make sure that all your processes agree on this coding (by having it be private to one class and linking in that class to all your processes, say). -- Joe Buck jbuck@galileo.berkeley.edu {uunet,ucbvax}!galileo.berkeley.edu!jbuck
tom@elan.Elan.COM (Thomas Smith) (01/10/91)
From article <CIMSHOP!DAVIDM.91Jan8174302@uunet.UU.NET>, by cimshop!davidm@uunet.UU.NET (David S. Masterson): > [ copy constructor definition deleted ] > How is memberwise assignment or initialization meant to handle virtual > functions and the hidden virtual function table pointer? Is the Vtabptr left > alone in this? > > The reason I ask this has to do with transmitting of objects from one process > to another. Assuming that type of the object is known after transmission, it > should be possible to cast the transmission buffer to that type and copy > construct a true object of that type using the buffer as input. Does this > make sense with respect to section 12.8 in the ARM? Rather than doing the cast in your above example, you might try overloading the 'new' operator. Define a new operator for your specific class that takes an additional pointer as a parameter. Your 'new' operator function would then take the passed pointer and use it in place of the usual free store. This will set up the virtual function table for you. There are examples of this technique in most manuals that I've seen - it is also used for implementing class-specific memory management. Hope this helps, Thomas Smith Elan Computer Group, Inc. (415) 964-2200 tom@elan.com, ...!{ames, uunet, hplabs}!elan!tom
davidm@uunet.UU.NET (David S. Masterson) (01/11/91)
>>>>> On 9 Jan 91 21:15:58 GMT, tom@elan.Elan.COM (Thomas Smith) said:
Thomas> Rather than doing the cast in your above example, you might try
Thomas> overloading the 'new' operator. Define a new operator for your
Thomas> specific class that takes an additional pointer as a parameter. Your
Thomas> 'new' operator function would then take the passed pointer and use it
Thomas> in place of the usual free store. This will set up the virtual
Thomas> function table for you. There are examples of this technique in most
Thomas> manuals that I've seen - it is also used for implementing
Thomas> class-specific memory management.
Hmmm, what references are you refering to? This sounds like an interesting
idea. I need to see some examples.
--
====================================================================
David Masterson Consilium, Inc.
(415) 691-6311 640 Clyde Ct.
uunet!cimshop!davidm Mtn. View, CA 94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"mjv@objects.mv.com (Michael J. Vilot) (01/13/91)
David Masterson asks about the effect of casting bits to create an object: > Assuming that type of the object is known after transmission, it > should be possible to cast the transmission buffer to that type and copy > construct a true object of that type using the buffer as input. It may indeed be possible, but as Joe Buck pointed out it may be neither portable nor guaranteed to work by any of the language's rules. The mechanics of virtual functions are clearly implementation-dependent (as they should be). Assuming you really want to pursue a design based on assembling bits in a buffer and not on using constructors to build up the objects, then you may be able to rely on the semantics of operator new. Specifically, the use of a ``placement expression.'' The number and type of arguments are up to you -- #include <new.h>, declare the operator new() that you need, and you may be able to develop the kind of solution you are after. Rather than a cast, you would ``allocate'' a new object and provide arguments to operator new() and/or the class' constructor. You can then dereference the pointer thus obtained and treat the resulting object in the usual way. Obviously, this design approach is a bit tricky, and requires careful cooperation between operator new, the constructor(s), and the destructor for the class. But it's more portable than relying on the result of a cast. More importantly, it stays within the type system. Hope this helps, -- Mike Vilot, ObjectWare Inc, Nashua NH mjv@objects.mv.com (UUCP: ...!decvax!zinn!objects!mjv)