Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!hellgate.utah.edu!cs.utexas.edu!milano!cadillac!vaughan@mcc.com
From: vaughan@mcc.com (Paul Vaughan)
Newsgroups: comp.lang.c++
Subject: Re: copy objects to another location
Message-ID: <2768@cadillac.CAD.MCC.COM>
Date: 11 Sep 89 15:28:34 GMT
References: <14265@polyslo.CalPoly.EDU> <9875@alice.UUCP>
Sender: news@cadillac.CAD.MCC.COM
Reply-To: vaughan@mcc.com (Paul Vaughan)
Distribution: usa
Organization: MCC VLSI CAD Program
Lines: 58
In-reply-to: shopiro@alice.UUCP (Jonathan Shopiro)


   In article <14265@polyslo.CalPoly.EDU>, ttwang@polyslo.CalPoly.EDU (Thomas Wang) writes:
   > I have discovered an interesting issue during the implementation of my
   > garbage collection project.
   > 
   > There does not appear to be a portable way to copy an object from one
   > memory location to another.  The operator '=' might be overloaded, so
   > I cannot depend on it for copying.
   > 
   The constructor X::X(const X&) has a special position in the language
   in that it is used for copying objects.  If X::X(const X&) is not declared,
   but X::X(X&) is, then the latter becomes the copy-constructor.  The copy-
   constructor is invoked when you initialize an X from another X, most
   commonly when passing an X to a function, or returning an X from a function.

   To move an object, you would probably use the copy-constructor with the
   placement allocation syntax, as in the following example:

	   void
	   move(const X& obj)	// obj is the object to be moved
	   {
		   void*	vp = <computation>;
		   // now vp contains the address where the copy of obj
		   // is to go
		   new (vp) X(obj);  // invokes the copy-constructor
		   obj.X::~X();      // invoke the destructor (without
		   // de-allocating storage) on the old copy
	   }

I have a couple of problems with this approach, the first is trivial,
the second arises from my confusion over what X::X(const X&)
definitions are supposed to do.  First, wouldn't the move function
need to be X::move(const X& x) instead of a normal function?
	Second, from Lippman's discussion on page 250, it appears that
it is reasonable to define copy constructors to copy the objects to
which the X object has pointers, especially when those objects are
(conceptually but not in actual class structure) considered to be
components of the X.  In Lippman's example, a String class has a copy
constructor that does a strcpy on its char* str.  Is this what is
desired when moving objects?  To move such a String object, it is
really only necessary to create a String object in a different place
with the same char* str (and of course be sure that any references to
the String are corrected).  It isn't necessary to copy the array of
characters.  On the other hand, it might make sense to go ahead and
copy the characters in order to improve locality in a GC application.
	At one point I was considering creating a system that could
relocate objects mostly as a way of changing the class of the object.
I had thought I might overload the -> operator to implement a
forwarding pointer scheme (sort of like a Lisp implementation) and
then just move objects at will.  This would let me change the class of
an object easily, whether or not the new object required more space.
I decided I didn't know how to that and put it off indefinitely (that
is, I blew it off :-).  One of my problems was how to copy objects and
whether it made sense to copy their components as the X::X(const X&)
would do.

 Paul Vaughan, MCC CAD Program | ARPA: vaughan@mcc.com | Phone: [512] 338-3639
 Box 200195, Austin, TX 78720  | UUCP: ...!cs.utexas.edu!milano!cadillac!vaughan