Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!pacbell.com!ucsd!ucbvax!pasteur!galileo.berkeley.edu!jbuck
From: jbuck@galileo.berkeley.edu (Joe Buck)
Newsgroups: comp.std.c++
Subject: Re: copies and copy constructors
Message-ID: <10557@pasteur.Berkeley.EDU>
Date: 29 Jan 91 01:58:39 GMT
References: <70198@microsoft.UUCP>
Sender: news@pasteur.Berkeley.EDU
Reply-To: jbuck@galileo.berkeley.edu (Joe Buck)
Lines: 49

In article <70198@microsoft.UUCP>, jimad@microsoft.UUCP (Jim ADCOCK) writes:
> Some questions:

> When a function returns-by-copy, is the region of memory that copy 
> resides in distinct? [bottom of ARM page 288 seems to be implying that
> C++ does indeed return-by-copy, but I guess one could even question that]

It implies that a copy constructor is used to copy the data, if a
copy is necessary.  In talks by Stroustrup and Koenig I've heard
discussion of optimizing away copy constructors, but can't find
any section in the ARM saying when you can do this.

> When, if ever, is it legal to invoke a copy constructor where
> the source and destination memory locations are identical?

I can't find any guarantee that this never happens.  I generally write
copy constructors to guard against this case arising somehow.

> When, if ever, is it legal to invoke a copy constructor where
> the source and destination memory locations are partially overlapping?

It would appear that this cannot happen unless there's a bug in memory
allocation, since the source argument is still in scope.  The only
relevant guarantee I can find is for default copy constructors, p. 298:

"Copying one object into another using the default copy constructor or
the default assignment operator does not change the structure of either
object."  This implies that the compiler writer can, for the case of
default constructors, use copy methods that assume non-overlapping memory.
I don't see how this restriction could be in force for default constructors
and go away when the user writes a constructor.

> When, if ever, is it legal to have partially overlapping references
> to the same object?

I'm not clear on what you mean by this.  Presumably you aren't talking
about a reference to a whole object partially overlapping with a reference
to one of its members.

|> [note that most of these questions could be applied separately for
|>  compiler-initiated actions [temporaries] and for programmer initiated
|>  actions, but I'm assuming that which a compiler is allowed to do,
|>  the programmer is allowed to do, and vice-versa]

Hence my extension of the guarantee on p. 298 to allow the user to
assume non-overlapping behavior for copy constructors.
--
Joe Buck
jbuck@galileo.berkeley.edu	 {uunet,ucbvax}!galileo.berkeley.edu!jbuck