From -7620265738555849352 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,f5d433881cc29cff X-Google-Attributes: gidf78e5,public From: bparker@gil.com.au (Brian Parker) Subject: Re: Named return value optimisation- reprise. Date: 1997/06/20 Message-ID: <33a885f3.6004413@news.ipswich.gil.com.au>#1/1 X-Deja-AN: 251292133 References: <33a345bf.7425526@news.ipswich.gil.com.au> <33A478C1.329@acm.org> <33A65B20.595D@aom.ericsson.se> <5o644g$3fj$1@toralf.uib.no> <5o7lbs$3a6@mulga.cs.mu.OZ.AU> <01bc7bf8$bb2c9be0$a56dadce@azguard> X-Original-Date: Thu, 19 Jun 1997 03:28:21 GMT Organization: Global Info-Links News Server X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUBM6o/0uEDnX0m9pzZAQHTbgGAhsXk66ZqzwOgdwwoW+4Ufy6vUv6NPEHC AYHa8jFX6FRu6exZwZIgRgDg4b76tTpG =Z4h+ Newsgroups: comp.std.c++ Originator: fjh@mundook.cs.mu.OZ.AU On 18 Jun 1997 09:06:47 PDT, "Bradd W. Szonye" wrote: >... >Okay, I finally looked up the rule in question after seeing these examples. >The trouble with 12.8/15 is that, in the presence of possible aliasing, >it's undecidable whether an object is actually used again. Take, for >example: > > void foo(T t) > { > T = tval1; > } > > int main() > { > T t = tval0; > T * tp = &t; > foo(t); > cout << *tp << endl; > } > >Does this print tval0 or tval1? It depends on whether the compiler performs >value-parameter optimization and on whether use of tp is a use of t. I >would argue that, even though it's an aliased use, it's still definitely a >use of t, and behaving otherwise would break reasonable programs. Yes, this example is non-controversial- t is definitely used. >example is very simple, however; it's not hard to construct examples where >it's not clear--not even to humans--whether an object is used again. >Practically speaking, except for compiler-generated temporaries and objects >which are otherwise about to go out of scope immediately, it's undecidable >whether "either the original object will never again be used." Actually, it's not even absolutely clear in the case of objects about to go out of scope- in a garbage-collected implementation memory can be retained beyond the local scope (or, as in the MV++ example, some of the object's memory may be statically allocated). >It's hard >even to come up with a reasonable definition of "used." > >I wouldn't mind seeing a non-normative note added to the example in 12.8/15 >to the effect that: "Determining whether an object is used again is in >general undecidable, and implementations should be conservative in applying >this optimization. In particular, an implementation should ensure that >pass-by-value has the expected semantics in the presence of aliases." It's >weaselly, true, but it would help discourage implementors from breaking >pass-by-value. > >Fortunately, the places where an object can "never again be used" are >decidable for the most useful optimizations: variables returned from >functions immediately before they go out of scope, and temporaries >constructed in the course of initializations. Those are the cases where >Machievelli could probably screw up the works, but Murphy is much less of a >problem. This was one of my original options for a fix for 12.8/15 too, but I now don't think it is useful as, being undecidable, it is ambiguous and hence has no place in a standard. For example, your assessment that the optimisation is safe in the case of the NRVO is not universally shared (well, it appears to be shared by everyone in the universe except me that is :-) ) and so a strict interpretation would also exclude the (N)RVO and hence one may just as well just remove 12.8/15. If it is decided to allow the (N)RVO then that would need an explicit paragraph allowing it, as in Jason Merrill's post, rather than trying to mend 12.8/15, IMHO. > >Don't forget that implementors don't want to break your code. That's why >some like Sun and Microsoft are slower to jump on the "new features" >bandwagon discussed elsewhere. Commercial compilers are much less likely to >optimize away pass-by-value than, say, experimental compilers. That's the danger though- code will be developed on a compiler that doesn't support these "optimisations" and it may only be many years later when the code is in production use that compilers which support these optimisations are used and these obscure bugs are manifest. ,Brian Parker (bparker@gil.com.au) --- [ 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 ]