From 4660301485541797738
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,f5d433881cc29cff
X-Google-Attributes: gidf78e5,public
From: fjh@mundook.cs.mu.OZ.AU (Fergus Henderson)
Subject: Re: Named return value optimisation- reprise.
Date: 1997/06/16
Message-ID: <5o2d5e$bs0@mulga.cs.mu.OZ.AU>#1/1
X-Deja-AN: 248859698
References: <33a345bf.7425526@news.ipswich.gil.com.au> <33A478C1.329@acm.org>
X-Original-Date: 16 Jun 1997 03:50:06 GMT
Organization: Comp Sci, University of Melbourne
X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUBM6VC+uEDnX0m9pzZAQF1TgF8CfpnE1IyMmeRaESuO9crQcONFZ4RVFhF 4N5L9Bfx0R4qutSeLZ7RhH9kMANFi7kJ =Srgc
Newsgroups: comp.std.c++
Originator: fjh@murlibobo.cs.mu.OZ.AU


Pete Becker <petebecker@acm.org> writes:

>Yes, if the copy construction were skipped then B would hold a pointer
>to 'a' instead of holding a pointer to a distinct array. Have I got this
>right?

Yep.

>	Skipping the copy constructor is not legal.  The object A consists of
>the storage allocated for A itself and the array 'a'. Since the array
>'a' is being accessed later (in order to see what happens to a[1]), the
>compiler is not permitted to eliminate the copy constructor.

I strongly disagree.  Brian Parker's interpretation of the draft is
correct: the object `A' consists of the storage allocated for `A' itself.
It does not include the array `a'.  The DWP is quite clear about this, IMHO.

>	The problem in the analysis of this issue lies in thinking that an
>"object" is only the members that we name. This is not correct. It is
>the region of memory that holds the data. All of the data, not part of
>it.

No, I disagree.  Your interpretation here is completely untenable, IMHO.

Firstly, it is not well-defined.  What exactly do you mean by
"all of the data"?  Do you mean all the data in the entire program?
If not, then what exactly? 

As far as I can tell, your definition of "object" is an unformalizable
"Humpty-Dumpty" definition: an object consists of what you want want it
to consist of, no more and no less.

Secondly, applying this interpretation of object to the rest of the DWP
would cause havoc.  For example, consider applying your definition of
object to 7.1.5.1/4:

|  7.1.5.1  The cv-qualifiers                               [dcl.type.cv]
...
|  4.	... any attempt to modify a const object during its lifetime
|	results in undefined behaviour.

Now take the following example:

	struct foo {
		int *p;
		foo(int *pp) : p(pp) {}
	};
	int i;
	const foo f(&i);
	i++;

Is `i' a part of the const object `f'? 
If so (as I would exect, assuming your definition of "object"),
then the behaviour is undefined.  But that is surely not the
intent of the committee, and would undoubtably lots of code.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]