named return value extension

named return value extension

[Carlo Wood]

Hi, after having upgraded to 2.97 (2.96 also started to crash on me)
I suddenly get the following warning on libcwd:

cc1plus: warnings being treated as errors
../../../libcw/src/libcwd/bfd.cc: In function `string full_path_to_executable()':
../../../libcw/src/libcwd/bfd.cc:502: warning: the named return value extension is deprecated.
../../../libcw/src/libcwd/bfd.cc:502: warning: Please see the documentation for details.

However, in the documentation - the only reference I could find is:

/usr/local/gcc/info>grep 'named return' gcc*
gcc.info-14:   The named return value extension has been deprecated, and will be

Where the paragraph at hand says:

   In the past, the GNU C++ compiler was extended to experiment with new
   features, at a time when the C++ language was still evolving. Now that
   the C++ standard is complete, some of those features are superseded by
   superior alternatives.
   ...
      The named return value extension has been deprecated, and will be
   removed from g++ at some point.

No details whatsoever :(

Can someone tell me what the "superior alternative" is for
the named return value extension?

Thanks,

-- 
Carlo Wood <carlo@alinoe.com>                        -=- Jesus Loves you -=-

Re: named return value extension

[Mike Stump]

> Date: Tue, 14 Nov 2000 19:30:25 +0100
> From: Carlo Wood <carlo@alinoe.com>
> To: gcc@gcc.gnu.org

> Where the paragraph at hand says:

>    In the past, the GNU C++ compiler was extended to experiment with new
>    features, at a time when the C++ language was still evolving. Now that
>    the C++ standard is complete, some of those features are superseded by
>    superior alternatives.
>    ...
>       The named return value extension has been deprecated, and will be
>    removed from g++ at some point.

> No details whatsoever :(

> Can someone tell me what the "superior alternative" is for
> the named return value extension?

Sure.  The Standardization committee deliberated at length about this
and came up with a solution.  The Standard permits the compiler to
optimize in several places were it wasn't permitted before.  Because
the compiler can now optimize objects in these more interesting ways,
the extension, which was merely a way of telling the compiler it was
ok to optimize, is largely unnecessary.  I won't try and recite all
the specifics about where the compiler can now optimize (I wouldn't
want to get it wrong), but instead I would refer you to the Standard
(cop out), or comp.std.c++.  A quick glance turns up:

  12.8  Copying class objects                               [class.copy]

15Whenever a class object is copied and the original object and the copy
  have  the  same  type, if the implementation can prove that either the
  original object or the copy will never again be  used  except  as  the
  result  of  an  implicit  destructor call (12.4), an implementation is
  permitted to treat the original and the copy as two different ways  of
  referring  to  the same object and not perform a copy at all.  In that
  case, the object is destroyed at the later of times when the  original
  and the copy would have been destroyed without  the  optimization.109)

which I think is what I was thinking of.