jimad@microsoft.UUCP (Jim ADCOCK) (01/24/91)
I'm trying to figure out where copies are "guaranteed" to exist and/or not to exist in C++, and I'm getting very confused. See Dec. JCLT for related ANSI-C issues. Part of the problem is that "copy" can be both a noun or verb thing. A "copy" can mean an invocation of a copy constructor, it can mean a separate region of memory, or it can mean both. The issue is important for "object oriented" - style programming where polymorphism and identity is important. Programmers must be able to "guarantee" in some situations that a copy is/is-not generated, so that the tests based on identity will work "correctly." In this sense, a "copy" means a distinct region of memory. 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] When, if ever, is it legal to invoke a copy constructor where the source and destination memory locations are identical? When, if ever, is it legal to invoke a copy constructor where the source and destination memory locations are partially overlapping? When, if ever, is it legal to have partially overlapping references to the same object? [please quote your sources when answering these questions] [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]
jbuck@galileo.berkeley.edu (Joe Buck) (01/29/91)
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