From 3797264443462085350
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/27
Message-ID: <33b33c08.5403399@news.ipswich.gil.com.au>#1/1
X-Deja-AN: 253005162
References: <199706172326.SAA05629@csrlink.net> <33a72f32.5732106@news.ipswich.gil.com.au> <33A8961E.403A3970@vandevoorde.com> <33aa7505.42328922@news.ipswich.gil.com.au> <01bc80b3$88b07be0$1771adce@azguard>
X-Original-Date: Fri, 27 Jun 1997 06:11:45 GMT
Organization: Global Info-Links News Server
X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBVAwUBM7P1rky4NqrwXLNJAQFybAH+LlyfGhv4016V+zupQ0pkWG++mmlIeqwl lJwas9MS3Co69GaZLvg/eAnX0Wkc85fl4GJ+HJ2z1OkJxC+P2FT3sQ== =iEU8
Newsgroups: comp.std.c++
Originator: austern@isolde.mti.sgi.com


On 25 Jun 97 04:24:00 GMT, "Bradd W. Szonye" <bradds@concentric.net>
wrote:
>...
>* In creating the temporary passed by 'return' the implementation may elide
>the calling of the copy constructor if the value returned is a
>compiler-generated temporary (RVO) or an automatic variable declared in the
>scope of the function (NRVO).
>
>* During initialization (of variables, function arguments, etc.), the
>implementation may elide compiler-generated temporaries.
>
>On the second point: this allows removal of duplicate "implicit conversion"
>temporaries created during function call and variable initialization and of
>the extra copy in "assignment-style" initialization, but not of named
>"temporaries" like formal parameters to functions.
>
>I think this covers all of the "usual" temporary elisions in C++. What it
>does not allow is lifetime analysis to find "dead" objects and reuse their
>storage. That's still possible (by the as-if rule) for built-ins and
>classes with no user-defined copy constructors or destructors in their
>ancestry.
> While it would be nice to allow lifetime merging, it's really
>only practical for objects with totally mechanical, value-like copy
>semantics. Any more than that, and you quickly run into a situation where
>the compiler and programmer are at odds about what the programmer meant.

Yes, if it is decided to make provision for the usual temporary
elisions in the standard, then 12.8/15 should explicitly specify the
cases where the temps can be elided.

I think that the following wording limits temp elision to these cases-

"12.8/15: 
In a copy-initialisation (8.5/12), if the source type is identical to
the destination type and is a class rvalue, or in a function return
(6.63) is an lvalue of automatic storage duration, then the copy can
be elided and the source object constructed directly in the
destination's storage."

,Brian Parker (bparker@gil.com.au)
---
[ 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 
]