From -6698463182364095880 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: 249358993 References: <33a345bf.7425526@news.ipswich.gil.com.au> <33A478C1.329@acm.org> <33A65B20.595D@aom.ericsson.se> X-Original-Date: 17 Jun 1997 18:21:56 -0700 Organization: Cygnus Solutions, Sunnyvale, CA X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBVAwUBM6gIC0y4NqrwXLNJAQGWwwH9HnyAD5oDQ8WKJhtjSDVOBg90iJB1wJfM e7B96J9ZeV39XaT9dYQQiWIt2LdQWLfqkZJzI+pIXRhLCHKHLjAjGw== =76DC Newsgroups: comp.std.c++ Originator: austern@isolde.mti.sgi.com >>>>> Mattias Lundstroem writes: > Jason Merrill wrote: >> But I'm OK with that. I'm comfortable saying that playing games with >> references and values in the same class, and relying on the copy >> constructor to switch between them, is asking for trouble. > My understanding is that the rule could break code like > that supplied by Brian Parker(below). Did anyone refute this? [STL "reverse_vec" example snipped] No, but I've proposed a more restricted version of 12.8p15 which restricts the optimization to return values. That version does not break Brian's testcase. Jason --- [ comp.std.c++ is moderated. To submit articles: Try just posting with your newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html Comments? mailto:std-c++-request@ncar.ucar.edu ]