🚀 go-pugleaf

In article I0J@netcom.com, arnstein@netcom.com (David Arnstein) writes:
>Gcc's "return" extension to c++ looks like this:
>
>   Integer  operator+  (const Integer& x, const Integer& y) return r
>   {
>     add(x, y, r);
>   }
>
>The "return r" clause in the first line prevents a copy of an Integer
>object on function return.
>
>Has the committee considered this extension?  It seems so sensible
>that I wonder why it was never adopted.

It seems to me that this extension does not involve any semantic change,
but provides only an explicit hint for an optimization. I don't see that
this hint tells the compiler any more than it could figure out for itself
in the absence of the extension. In many cases compilers can and do
optimize away extra copies of a returned value.

Could you supply an example where the extension necessarily allows the
compiler to generate better code? That is, without the extension you
would have to write the code slightly differently. I'd like to see an
example where the C++ semantic rules require less efficient code than
that allowed by the extension.
---
Steve Clamage, stephen.clamage@eng.sun.com



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <45ejq1$ojo@engnews2.Eng.Sun.COM>, clamage@Eng.Sun.COM wrote:

> It seems to me that this extension does not involve any semantic change,
> but provides only an explicit hint for an optimization. I don't see that
> this hint tells the compiler any more than it could figure out for itself
> in the absence of the extension. In many cases compilers can and do
> optimize away extra copies of a returned value.
> 
> Could you supply an example where the extension necessarily allows the
> compiler to generate better code? That is, without the extension you
> would have to write the code slightly differently. I'd like to see an
> example where the C++ semantic rules require less efficient code than
> that allowed by the extension.

You've missed the point.  Programmers go to a lot of trouble to take advantage
of certain kinds of optimizations, and have to change their program if these
optimizations don't work.  So portability isn't a big win here, unless the
optimization itself is implemented in every compiler.

The gnu approach is a very simple, almost too obviously simple of a solution
for a compiler person to appreciate.  For the user, however, it is a godsend,
because he can now program in a certain style and be reasonably certain that
a certain very important optimization will be performed.  Most users aren't
looking for 'cute'/'smart' compilers, but 'reliable'/'understandable'
compilers.

If the standards committee wants to make certain optimizations mandatory,
then that would be another solution, but I think that that is a slippery
slope.

-- 
www/ftp directory:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <45ejq1$ojo@engnews2.Eng.Sun.COM> clamage@Eng.Sun.COM
(Steve Clamage) writes:

|> In article I0J@netcom.com, arnstein@netcom.com (David Arnstein) writes:
|> >Gcc's "return" extension to c++ looks like this:

|> >   Integer  operator+  (const Integer& x, const Integer& y) return r
|> >   {
|> >     add(x, y, r);
|> >   }

|> >The "return r" clause in the first line prevents a copy of an Integer
|> >object on function return.

|> >Has the committee considered this extension?  It seems so sensible
|> >that I wonder why it was never adopted.

|> It seems to me that this extension does not involve any semantic change,
|> but provides only an explicit hint for an optimization. I don't see that
|> this hint tells the compiler any more than it could figure out for itself
|> in the absence of the extension. In many cases compilers can and do
|> optimize away extra copies of a returned value.

I suspect that it would depend on the semantics actually given the
return variable.  At present, the compiler cannot optimize out a named
variable; the variable named by return being a special case, the
committee could authorize eliding it.

Take for example the classic (and obvious) implementation of
operator+:

	MyClass
	operator+( MyClass const& op1 , MyClass const& op2 )
	{
	    MyClass         result( op1 ) ;
	    op1 += op2 ;
	    return op1 ;
	}

When used as an initializer, for example, the compiler must (under the
present rules) call two constructors: one for result, and then a copy
constructor for the named variable being initialized, since both of
the variables are named.

Traditionally, programmers are thus encouraged to avoid the named
variable, writing something like the following:

	MyClass
	operator+( MyClass const& op1 , MyClass const& op2 )
	{
	    return MyClass( op1 ) += op2 ;
	}

Personally, I find this very ugly, and would much prefer something
along the lines of:

	MyClass
	operator+( MyClass const& op1 , MyClass const& op2 )
	    return result( op1 )
	{
	    result += op2 ;
	}

This could generate the same code if the standard gave the compiler
explicit autorization to elide the variable named in the return
clause.

This said, I think it is a minor point, and it is much to late to be
considering such proposals now.
--

James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]