🚀 go-pugleaf

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. ]