From -4049227897416681299 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,f5d433881cc29cff X-Google-Attributes: gidf78e5,public From: fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) Subject: Re: Named return value optimisation- reprise. Date: 1997/06/20 Message-ID: <5odevo$a5g@mulga.cs.mu.OZ.AU>#1/1 X-Deja-AN: 251381618 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: 20 Jun 1997 08:28:40 GMT Organization: Comp Sci, University of Melbourne X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBVAwUBM6q74ky4NqrwXLNJAQHgngIAhlMA6HHHZcBkYQYN76x7hvpgBd9lVG4t aJJDei9P6pyQAwkr6co1Z55dZC4b8YAYu3K0Gs/eQ3LEFAzxqALOvA== =cInM Newsgroups: comp.std.c++ Originator: austern@isolde.mti.sgi.com "Bradd W. Szonye" writes: >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. That's not necessarily a problem. Equivalence of programs is also undecidable, but compilers perform equivalence-preserving transformations all the time. In fact, most interesting program properties are undecidable. The trouble with 12.8/15 as interpreted using the standard definition of object is that it causes some programs to have anomalous and unexpected semantics, as exhibited by the many examples in this thread. The trouble with 12.8/15 as interpreted using Pete Becker's interpretation of "object" is that it is not well-defined. Being undecidable would be OK, but being not well-defined is not. >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, I think everyone agrees that this constitutes use of the object. >This 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. Sure, but that's not a problem. A compiler should optimize such examples only if it can prove that the object won't be used again. For example, consider the following code: T foo() { T x; T x2(x); if (there_is_a_counter_example_to_fermats_last_theorem()) { use(x); } return x2; } In this example, it is very difficult to figure out whether or not `x' will be used again. If the compiler can prove that the function there_is_a_counter_example_to_fermats_last_theorem() will never return `true', then it can use 12.8/15 to use the same storage for `x' and `x2'. However, it should only apply this optimization if it can indeed find such a proof (and in general, finding such a proof might be arbitrarily difficult). >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. If that is the intent, then it should be expressed in normative text, not in a non-normative note. The standard should express a clear contract between users and implementors. There is a place for implementation advice ("should" rather than "shall") but I think that the standard should clearly define the semantics of basic features of the language like pass-by-value. -- Fergus Henderson | "I have always known that the pursuit WWW: | 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 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 ]