This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: named return value extension

> Date: Tue, 14 Nov 2000 19:30:25 +0100
> From: Carlo Wood <>
> To:

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]