From 8422850755578192028 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,f5d433881cc29cff X-Google-Attributes: gidf78e5,public From: Jason Merrill Subject: Re: Named return value optimisation- reprise. Date: 1997/06/18 Message-ID: #1/1 X-Deja-AN: 249212950 References: <33a345bf.7425526@news.ipswich.gil.com.au> <33A478C1.329@acm.org> <33a5f9a1.5157214@news.ipswich.gil.com.au> X-Original-Date: 17 Jun 1997 15:22:53 -0700 Organization: Cygnus Solutions, Sunnyvale, CA X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUBM6dE3eEDnX0m9pzZAQGhkAF+IRnxcvyOZ3vzPeY5j3qOTFTkfmhnKbtg uherf80ZRuTmZJtdXXVfTHk+y6CKSPB8 =+OGo Newsgroups: comp.std.c++ Originator: fjh@mundook.cs.mu.OZ.AU >>>>> Brian Parker writes: > Trouble is, the STL also plays aliasing games. In fact, many classes > using dynamically allocated memory would fall prey to the 12.8/5 bugs. > I repeat here a previously posted example using STL (it involves > 12.8/5 being used to elide the copy on pass-by-value). In this testcase, the problem occurs because even though 'v' is not directly used after the call, references to data it controls are. This would not be a problem if 'v' went out of scope immediately after the call, because any references to its data are undefined after it goes out of scope. Thus, I suggest that 12.8/15 should be reworded to read 15Whenever an automatic (_basic.stc.auto_) class object is copied and the original object and the copy have the same type, and the block containing the original object exits (_stmt.jump_) immediately after the copy is created, an implementation is permitted to treat the original and the copy as two different ways of referring to the same object and not perform a copy at all. In that case, the object is destroyed when the copy would have been destroyed without the optimization. I think this only allows the RVO. Jason --- [ 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 ]