Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ucbvax!pasteur!galileo.berkeley.edu!jbuck From: jbuck@galileo.berkeley.edu (Joe Buck) Newsgroups: comp.lang.c++ Subject: Re: Copy constructors Message-ID: <10090@pasteur.Berkeley.EDU> Date: 9 Jan 91 05:43:21 GMT References: Sender: news@pasteur.Berkeley.EDU Reply-To: jbuck@galileo.berkeley.edu (Joe Buck) Distribution: comp Lines: 46 In article , 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