In article <1993Nov12.200501.27974@lpi.liant.com>,
Scott Turner <pkt@lpi.liant.com> wrote:
>> >> HugeInt operator-(HugeInt const &l, HugeInt const &r) {
>> >>     HugeInt t = l;  // 1
>> >>     t -= r;   // 2
>> >>     return t;   // 3
>> >> }
>> >> Can &returnvalue==&t?
>[...]
>I was ignoring the commentary part of the ARM.  Section 12.2 does not
>endorse this optimization, although the ARM's commentary in 12.1.1c does.

But where does the ARM require a distinct "return value object"?  ARM
6.6.3 The return Statement: "IF REQUIRED, the expression is converted
... to the return type of the function ...  THIS may involve the
construction and copy of a temporary object (12.2)".  (emphasis
mine).  Does the ARM require the construction of a temporary object
(the "return value object"?) when no conversion is required for the
return expression?

Considering section 12 commentary, it's obvious that optimizing away
`t' (or is it optimizing away a distinct return value?) was intended
to be legal.  I would bet it will be legal ANSI/ISO C++.  I'm just
curious whether it's generally accepted that a strict reading of the
ARM disallows the optimization.

>> Are we talking about the elimination of a temporary in:
>>  X f();
>>  main() {
>>     X b = f();
>>  }
>That's a different optimization, which _is_ mentioned in 12.2.

Okay, I see the difference now, but where does the ARM require that
the "return value" of a function must be a distinct object from the
(local) object being returned.  I guess the closest thing is 12.6.1
"The initialization that occurs in argument passing and function
return is equivalent to the form `T x = a;'".  I just wish that the
ARM explicitly said that `x' is the "return value object" (and maybe
mentioned it in 6.6.3).  The ARM could then have mentioned the "return
value object" is an elidable temporary in 12.2.

Jamshid Afshar
jamshid@ses.com

In article <CGvKFG.tr@ses.com>, jamshid@ses.com (Jamshid Afshar) writes:
> In article <1993Nov12.200501.27974@lpi.liant.com>,
> Scott Turner <pkt@lpi.liant.com> wrote:
> >> >> HugeInt operator-(HugeInt const &l, HugeInt const &r) {
> >> >>     HugeInt t = l;  // 1
> >> >>     t -= r;   // 2
> >> >>     return t;   // 3
> >> >> }
> >> >> Can &returnvalue==&t?
> >[...]
> >I was ignoring the commentary part of the ARM.  Section 12.2 does not
> >endorse this optimization, although the ARM's commentary in 12.1.1c does.
>
> But where does the ARM require a distinct "return value object"?  ARM
> 6.6.3 The return Statement: "IF REQUIRED, the expression is converted
> ... to the return type of the function ...  THIS may involve the
> construction and copy of a temporary object (12.2)".  (emphasis
> mine).  Does the ARM require the construction of a temporary object
> (the "return value object"?) when no conversion is required for the
> return expression?
>
> Considering section 12 commentary, it's obvious that optimizing away
> `t' (or is it optimizing away a distinct return value?) was intended
> to be legal.  I would bet it will be legal ANSI/ISO C++.  I'm just
> curious whether it's generally accepted that a strict reading of the
> ARM disallows the optimization.

When the issue comes up within the core language working group, eventually
Andy Koenig or someone else always mentions wording that Jerry Schwarz has
suggested, as a possible answer.

    If some object y is initialized
    from some other object x, and x is subsequently never used,
    the compiler should be entitled to treat y as an alias for x,
    implicitly extending the lifetime of x to be at least as long
    as that of y.

It is generally accepted that an explicit provision of that kind must be
added to what's in the ARM, if the C++ standard is to support the
return value optimization.  On the other hand, committee discussions
usually bypass the ARM's lack of a rule governing the value which
  return t;
returns to its caller.  It would be easier to discuss this "optimization"
if we had a standard meaning to compare it to.
--
Prescott K. Turner, Jr.
Liant Software Corp. (developers of LPI languages)
959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com