Re: Named Return Value Extension Proposal

Re: Named Return Value Extension Proposal

[E. Robert Tisdale]

Gabriel Dos Reis wrote:

> I don't know what will be decided,
> but let me throw my 0.02 euros in there.
> I certainly don't minimize the importance of compiler level optimizations.
> But it's my opinion that there are ISO C++ language features--
> not optimizations-- that need to be fixed or implemented in the compiler.
> That already is a lot of work to do.  I'm not particularly interested
> in seeing a lot of work spent in implementing nonstandard features,
> that will probably badly interact with ISO C++,
> whereas there are more fundamental topics waiting to be addressed.
>
> So my proposal will be: let's first catch up the Standard,
> then we'll address optimizations issues.
>
> Just because a particular optimization is _permitted_
> doesn't mean that the compiler *should* implement it,
> particularly when the compiler is trying hard to get semantics right.

Gaby, You and I will both grow very old and die
before this compiler catches up with the standard.
I don't think that it is too unreasonable for me and other users
to expect the compiler to produce reasonably fast and efficient code
without hacking our source to work around a deficient optimizer.

It appears from the reply by Jason Merrill <jason@cygnus.com>
to the "elided copy constructors" thread that it will be a very long time
before the changes can be made to implement the optimizations
permitted by the standard.  I am simply proposing a stop gap
to carry us through until it is possible to implement the optimizations.

I have taken some pain to ensure that the proposed extensions
will not interact badly with the ANSI/ISO C++ standard.
Please let us know if you see something wrong that I don't see.

> just my 0.02 euros.

I'll see your 0.02 euros and raise you $0.02

E. Robert Tisdale <edwin@netwood.net>

Re: Named Return Value Extension Proposal

[Mark Mitchell]

>>>>> "E" == E Robert Tisdale <edwin@netwood.net> writes:

    E> Gaby, You and I will both grow very old and die before this
    E> compiler catches up with the standard.  

Lots of us are working hard to see that we do indeed reach compliance.

    E> It appears from the reply by Jason Merrill <jason@cygnus.com>
    E> to the "elided copy constructors" thread that it will be a very
    E> long time before the changes can be made to implement the
    E> optimizations permitted by the standard.

That may or may not be true.  Jason said that it is not easy, and that
is true.

On the other hand, neither are member templates, global common
sub-expression elimination, or a new standard library.  The first two
projects are complete, to a reasonably strict definition of complete,
while the third is well underway.

    E>   I am simply proposing a stop gap to carry us through until it
    E> is possible to implement the optimizations.

We have too many such stop-gaps already in g++.  We really don't want
to add additional language extensions at this point, IMO.

-- 
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Named Return Value Extension Proposal

[Gabriel Dos Reis]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2210 bytes --]

>>>>> «ERT», E Robert Tisdale <edwin@netwood.net> wrote:

> Gaby, You and I will both grow very old and die
> before this compiler catches up with the standard.

Probably. But I don't consider it a reason to make harder the
already painful task of attempting to implement it. Neither a reason to
*require* EGCS developpers to implement a language beside the scope of
ISO C++.

> I don't think that it is too unreasonable for me and other users
> to expect the compiler to produce reasonably fast and efficient code
> without hacking our source to work around a deficient optimizer.

> It appears from the reply by Jason Merrill <jason@cygnus.com>
> to the "elided copy constructors" thread that it will be a very long time
> before the changes can be made to implement the optimizations
> permitted by the standard.  I am simply proposing a stop gap
> to carry us through until it is possible to implement the optimizations.

It will take long time to any compiler to implement optimizations
permitted by ISO C++.

> I have taken some pain to ensure that the proposed extensions
> will not interact badly with the ANSI/ISO C++ standard.
> Please let us know if you see something wrong that I don't see.

Well, as the named return value is an optimization, how can an
application programmer can portably, that is in the scope of ISO C++,
detect whether the compiler is supporting or is going to perform the
named return optimization? He will have to resort to some crippled
extensions. That extension would require lot of work from compiler
writers. 

Given your extension how would the compiler detect that an
application programmer really wanted the NRVO and didn't make a
synatxe error? Ah, the compiler should assume the application
programmer can never make such an error?

Don't get me wrong. I'm highly concerned with optimizations especially
the NRVO; I would be happy to see it in EGCS. But given the state of
the EGCS/g++ compiler, I would like to see work spent on fixing more
fundamental bugs and implementing lacking features (not optimizations).
I don't consider the NRVO as an urgent issue.

You don't have to agree with me, but just accept I have another
opinion on the question.

-- Gaby

Re: Named Return Value Extension Proposal

[Martin v. Loewis]

>     E>   I am simply proposing a stop gap to carry us through until it
>     E> is possible to implement the optimizations.
> 
> We have too many such stop-gaps already in g++.  We really don't want
> to add additional language extensions at this point, IMO.

Which brings us back to a thread of a few days ago :-) If somehow
appears an implementation of such a stop-gap, and it is clean in the
sense that it doesn't break anything and is easily maintainable, and
it solves a real need - I would be in favour of accepting such an
implementation.

Of course, I would never consider doing it myself, for the reasons
you've mentioned.

Regards,
Martin

Re: Named Return Value Extension Proposal

[E. Robert Tisdale]

Gabriel Dos Reis wrote:

> I don't know what will be decided,
> but let me throw my 0.02 euros in there.
> I certainly don't minimize the importance of compiler level optimizations.
> But it's my opinion that there are ISO C++ language features--
> not optimizations-- that need to be fixed or implemented in the compiler.
> That already is a lot of work to do.  I'm not particularly interested
> in seeing a lot of work spent in implementing nonstandard features,
> that will probably badly interact with ISO C++,
> whereas there are more fundamental topics waiting to be addressed.
>
> So my proposal will be: let's first catch up the Standard,
> then we'll address optimizations issues.
>
> Just because a particular optimization is _permitted_
> doesn't mean that the compiler *should* implement it,
> particularly when the compiler is trying hard to get semantics right.

Gaby, You and I will both grow very old and die
before this compiler catches up with the standard.
I don't think that it is too unreasonable for me and other users
to expect the compiler to produce reasonably fast and efficient code
without hacking our source to work around a deficient optimizer.

It appears from the reply by Jason Merrill <jason@cygnus.com>
to the "elided copy constructors" thread that it will be a very long time
before the changes can be made to implement the optimizations
permitted by the standard.  I am simply proposing a stop gap
to carry us through until it is possible to implement the optimizations.

I have taken some pain to ensure that the proposed extensions
will not interact badly with the ANSI/ISO C++ standard.
Please let us know if you see something wrong that I don't see.

> just my 0.02 euros.

I'll see your 0.02 euros and raise you $0.02

E. Robert Tisdale <edwin@netwood.net>

Re: Named Return Value Extension Proposal

[Mark Mitchell]

>>>>> "E" == E Robert Tisdale <edwin@netwood.net> writes:

    E> Gaby, You and I will both grow very old and die before this
    E> compiler catches up with the standard.  

Lots of us are working hard to see that we do indeed reach compliance.

    E> It appears from the reply by Jason Merrill <jason@cygnus.com>
    E> to the "elided copy constructors" thread that it will be a very
    E> long time before the changes can be made to implement the
    E> optimizations permitted by the standard.

That may or may not be true.  Jason said that it is not easy, and that
is true.

On the other hand, neither are member templates, global common
sub-expression elimination, or a new standard library.  The first two
projects are complete, to a reasonably strict definition of complete,
while the third is well underway.

    E>   I am simply proposing a stop gap to carry us through until it
    E> is possible to implement the optimizations.

We have too many such stop-gaps already in g++.  We really don't want
to add additional language extensions at this point, IMO.

-- 
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Named Return Value Extension Proposal

[Martin v. Loewis]

>     E>   I am simply proposing a stop gap to carry us through until it
>     E> is possible to implement the optimizations.
> 
> We have too many such stop-gaps already in g++.  We really don't want
> to add additional language extensions at this point, IMO.

Which brings us back to a thread of a few days ago :-) If somehow
appears an implementation of such a stop-gap, and it is clean in the
sense that it doesn't break anything and is easily maintainable, and
it solves a real need - I would be in favour of accepting such an
implementation.

Of course, I would never consider doing it myself, for the reasons
you've mentioned.

Regards,
Martin

Re: Named Return Value Extension Proposal

[Gabriel Dos Reis]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2210 bytes --]

>>>>> «ERT», E Robert Tisdale <edwin@netwood.net> wrote:

> Gaby, You and I will both grow very old and die
> before this compiler catches up with the standard.

Probably. But I don't consider it a reason to make harder the
already painful task of attempting to implement it. Neither a reason to
*require* EGCS developpers to implement a language beside the scope of
ISO C++.

> I don't think that it is too unreasonable for me and other users
> to expect the compiler to produce reasonably fast and efficient code
> without hacking our source to work around a deficient optimizer.

> It appears from the reply by Jason Merrill <jason@cygnus.com>
> to the "elided copy constructors" thread that it will be a very long time
> before the changes can be made to implement the optimizations
> permitted by the standard.  I am simply proposing a stop gap
> to carry us through until it is possible to implement the optimizations.

It will take long time to any compiler to implement optimizations
permitted by ISO C++.

> I have taken some pain to ensure that the proposed extensions
> will not interact badly with the ANSI/ISO C++ standard.
> Please let us know if you see something wrong that I don't see.

Well, as the named return value is an optimization, how can an
application programmer can portably, that is in the scope of ISO C++,
detect whether the compiler is supporting or is going to perform the
named return optimization? He will have to resort to some crippled
extensions. That extension would require lot of work from compiler
writers. 

Given your extension how would the compiler detect that an
application programmer really wanted the NRVO and didn't make a
synatxe error? Ah, the compiler should assume the application
programmer can never make such an error?

Don't get me wrong. I'm highly concerned with optimizations especially
the NRVO; I would be happy to see it in EGCS. But given the state of
the EGCS/g++ compiler, I would like to see work spent on fixing more
fundamental bugs and implementing lacking features (not optimizations).
I don't consider the NRVO as an urgent issue.

You don't have to agree with me, but just accept I have another
opinion on the question.

-- Gaby

Re: Named Return Value Extension Proposal

[E. Robert Tisdale]

Mike Stump wrote:

> > From: "E. Robert Tisdale" <edwin@netwood.net>
>
> > It solves the problem that the egcs compiler has with function X f1(int)
> > but the function definition is entirely incompatible with ANSI C++
>
> Yes.
>
> > and it cannot solve the problem that the compiler has with function
> > X g0(X).
>
> Why not?
>
> X g0(X x) return x(x) {
>   cerr << "The copy constructor may be called for g0(X)." << endl;
>   return x;
> }
>
> If this doesn't scope this way now,
> I don't see it as a problem to fix it so that it does,
> and so that the semantics of it just work the way you expect.

Not quite.  The function prototype is X g0(X);
which means that the compiler creates a temporary
for argument X when X g0(X) is called
then the copy constructor is called to initialize
the return value for g0(X) before entering
the body of the function.

E. Robert Tisdale <edwin@netwood.net>

Re: Named Return Value Extension Proposal

[Mike Stump]

One more thought...

> Date: Mon, 22 Mar 1999 13:07:13 -0800
> From: "E. Robert Tisdale" <edwin@netwood.net>
> To: egcs@egcs.cygnus.com

> X       g0(X x) {
>   cerr << "The copy constructor may be called for g0(X)." << endl;
>   return x;
>   }

> The current extension is very old now and it seems unlikely to me
> that it will ever be adopted as part of the ANSI C++ standard.

Right.

> It solves the problem that the egcs compiler has with function X f1(int)
> but the function definition is entirely incompatible with ANSI C++

Yes.

> and it cannot solve the problem that the compiler has with function
> X g0(X).

Why not?

X g0(X x) return x(x) {
  cerr << "The copy constructor may be called for g0(X)." << endl;
  return x;
}
  
If this doesn't scope this way now, I don't see it as a problem to fix
it so that it does, and so that the semantics of it just work the way
you expect.

> Of course, the current named value extension must be retained for
> backward compatibility but I propose a simple extension which
> permits the C++ programmer to insert the `return' keyword between
> the type and the name in a declaration to identify the name as a
> reference to the return value as shown below:

Your proposal is `better' than the original Name Value extension.  If
you proposed it 9 years ago, I would have voted that we do it instead
of the one that is in g++ now.  Now it is too late.  :-(

Because your proposal doesn't appear to bring anything new to the
table (stuff the existing extension already does), except for a
slightly more ANSI C++ feel to it.  I don't feel this slightly better
syntax is enough to want me to support the addition of an alternate
spelling of a preexisting hack.

Maybe someone will key off your pain, and devise a way to put in the
elision code that will `solve' this problem...  Make a great project
for someone that wants to play.

Re: Named Return Value Extension Proposal

[Mike Stump]

Sounds great, but I missed the proof where you showed the compiler
can't figure this out for itself.  :-( I instead favor having the
compile do the hard work, and not require having the user try and code
in something besides ANSI C++ in this case.

Re: Named Return Value Extension Proposal

[E. Robert Tisdale]

Mike Stump wrote:

> > Date: Mon, 22 Mar 1999 20:04:10 -0800
> > From: "E. Robert Tisdale" <edwin@netwood.net>
> > To: egcs@egcs.cygnus.com
>
> > Mike Stump wrote:
>
> > > > From: "E. Robert Tisdale" <edwin@netwood.net>
> > >
> > > > It solves the problem that the egcs compiler has with function X f1(int)
> > > > but the function definition is entirely incompatible with ANSI C++
> > >
> > > Yes.
> > >
> > > > and it cannot solve the problem that the compiler has with function
> > > > X g0(X).
> > >
> > > Why not?
> > >
> > > X g0(X x) return x(x) {
> > >   cerr << "The copy constructor may be called for g0(X)." << endl;
> > >   return x;
> > > }
> > >
> > > If this doesn't scope this way now,
> > > I don't see it as a problem to fix it so that it does,
> > > and so that the semantics of it just work the way you expect.
>
> > Not quite.  The function prototype is X g0(X); which means that the
> > compiler creates a temporary for argument X when X g0(X) is called
> > then the copy constructor is called to initialize the return value
> > for g0(X) before entering the body of the function.
>
> Maybe I am just being slow...
>
> And does your new extension fix this problem?  If it does,
> how can it, and can't the existing extension fix it the same way?
> If not, why not?  If so, I still claim they are identical
> and that your listing of g0 was unfair and misleading.

I don't know why you are confused.
Perhaps you just haven't noticed that your version

> X g0(X x) return x(x) {
>   cerr << "The copy constructor may be called for g0(X)." << endl;
>   return x;
>   }

was not defined to be inline.
Your version of X g0(X) may be a library function
and the definition may not be visible to the compiler.
If so, the compiler has only the function prototype X g0(X)
for your version which doesn't tell it that the argument
is simply a reference to the return value
but the prototype X g0(X return) for my version
would include this information
so that the calling program can call a constructor
to initialize the return value instead of the function argument.
The calling program does not actually pass an argument
to my version of X g0(X return)  because the "argument"
is actually just a reference to the return value.

Hope this helps, E. Robert Tisdale <edwin@netwood.net>

Re: Named Return Value Extension Proposal

[Mike Stump]

> Date: Mon, 22 Mar 1999 20:04:10 -0800
> From: "E. Robert Tisdale" <edwin@netwood.net>
> To: egcs@egcs.cygnus.com

> Mike Stump wrote:

> > > From: "E. Robert Tisdale" <edwin@netwood.net>
> >
> > > It solves the problem that the egcs compiler has with function X f1(int)
> > > but the function definition is entirely incompatible with ANSI C++
> >
> > Yes.
> >
> > > and it cannot solve the problem that the compiler has with function
> > > X g0(X).
> >
> > Why not?
> >
> > X g0(X x) return x(x) {
> >   cerr << "The copy constructor may be called for g0(X)." << endl;
> >   return x;
> > }
> >
> > If this doesn't scope this way now,
> > I don't see it as a problem to fix it so that it does,
> > and so that the semantics of it just work the way you expect.

> Not quite.  The function prototype is X g0(X); which means that the
> compiler creates a temporary for argument X when X g0(X) is called
> then the copy constructor is called to initialize the return value
> for g0(X) before entering the body of the function.

Maybe I am just being slow...

And does your new extension fix this problem?  If it does, how can it,
and can't the existing extension fix it the same way?  If not, why
not?  If so, I still claim they are identical and that your listing of
g0 was unfair and misleading.

Named Return Value Extension Proposal

[E. Robert Tisdale]

My egcs-2.90.29 980515 (egcs-1.0.3 release) compiler 
does not always elide copy constructors as permitted
by the ANSI C++ standard so I propose an extension
to the C++ language similar to named return values
which the C++ programmer can use to help the compiler
identify names which reference the return value.

The following test program illustrates the problem:

----------------------------------------------------------------------
// test.cc

#include<iostream>

class X {                       // a dynamic array class
  // representation
  int*  p;                      // pointer to a huge array
  int   n;                      // length of the huge array
  public:
  // constructors
  explicit
  X(int k):                     // explicit constructor definition
    p(new int[k]), n(k) { }
  X(const X& x);                // copy constructor declaration
 ~X(void) {                     // destructor definition
    if (p) delete [] p; }
  // functions
  int   length(void) const { return n; }
  // operators
  const
  int&  operator [](int j) const { return p[j]; }
  int&  operator [](int j)       { return p[j]; }
  };

X::X(const X& x):               // copy constructor definition
  p(new int[x.n]), n(x.n) {
  cerr << "The copy constructor was called!" << endl;
  for (int j = 0; j < n; j++)   // copy the array
    p[j] = x.p[j];
  }

// user defined functions

#define __return__

inline
X       f0(int n) {
  cerr << "The copy constructor may be called for f0(int)." << endl;
  return X(n);
  }
inline
X       f1(int n) {
  X __return__ x(n);
  for (int j = 0; j < n; j++)   // Modify x.
    x[j] = j;
  cerr << "The copy constructor may be called for f1(int)." << endl;
  return x ;
 }
inline
X       f2(int n) return x(n) {
  for (int j = 0; j < n; j++)   // Modify x.
    x[j] = j;
 }
inline
X       g0(X x) {
  cerr << "The copy constructor may be called for g0(X)." << endl;
  return x;
  }
inline
X       g1(const X& x) {
  cerr << "The copy constructor must be called for g1(const X&)." << endl;
  return x;
  }

int
main () {
  cerr << endl
       << "The copy constructor may be called for X x0 = f0(32);" << endl;
  X x0 = f0(32);
  cerr << endl
       << "The copy constructor may be called for X x1 = f1(32);" << endl;
  X x1 = f1(32);
  cerr << endl
       << "The copy constructor may be called for X x2 = f2(32);" << endl;
  X x2 = f2(32);
  cerr << endl
       << "The copy constructor may be called for X y0 = g0(f0(32));" << endl;
  X y0 = g0(f0(32));
  cerr << endl
       << "The copy constructor may be called for X y1 = g1(x1);" << endl;
  X y1 = g1(x1);
  cerr << endl
       << "The copy constructor must be called for X z0 = y0;" << endl;
  X z0 = y0;
  return 0;
  }
----------------------------------------------------------------------

I compiled and ran the `test' program as follows:

----------------------------------------------------------------------
$ uname -rms
Linux 2.0.36 i686
$ g++ --version
egcs-2.90.29 980515 (egcs-1.0.3 release)
$ g++ -O2 -felide-constructors -o test test.cc
./test

The copy constructor may be called for X x0 = f0(32);
The copy constructor may be called for f0(int).

The copy constructor may be called for X x1 = f1(32);
The copy constructor may be called for f1(int).
The copy constructor was called!

The copy constructor may be called for X x2 = f2(32);

The copy constructor may be called for X y0 = g0(f0(32));
The copy constructor may be called for f0(int).
The copy constructor may be called for g0(X).
The copy constructor was called!

The copy constructor may be called for X y1 = g1(x1);
The copy constructor must be called for g1(const X&).
The copy constructor was called!

The copy constructor must be called for X z0 = y0;
The copy constructor was called!
$ 
----------------------------------------------------------------------

Function X f2(int) illustrates the named return value extension
as currently supported by my egcs compiler.  See the GCC manual at

        http://egcs.cygnus.com/onlinedocs/gcc_5.html#SEC102

The current extension is very old now and it seems unlikely to me
that it will ever be adopted as part of the ANSI C++ standard.
It solves the problem that the egcs compiler has with function X f1(int)
but the function definition is entirely incompatible with ANSI C++ and
it cannot solve the problem that the compiler has with function X g0(X).

Of course, the current named value extension must be retained
for backward compatibility but I propose a simple extension
which permits the C++ programmer to insert the `return' keyword
between the type and the name in a declaration to identify the name
as a reference to the return value as shown below:

----------------------------------------------------------------------
inline
X       f(int n) {
  X return x(n);                // x is a reference to the return value.
                                // Call the X(n) constructor to initialize it.
  for (int j = 0; j < n; j++)   // Modify x.
    x[j] = j;
  return x;                     // Don't call the copy constructor!
                                // Don't call the destructor for x!
 }

inline
X       g(X return x) {         // x is a reference to the return value.
  for (int j = 0; j < n; j++)   // Modify x.
    x[j] = j;
  return x;                     // Don't call the copy constructor!
                                // Don't call the destructor for x!
  }
----------------------------------------------------------------------

The constructor which would normally be called to initialize
a temporary argument for g(X) would initialize the return value instead
even if the the return value is not a temporary:

----------------------------------------------------------------------
int
main () {
  X x(n);
  X y = g(x);                   // Don't create any temporary values.
                                // Call the copy constructor
                                // to initialize y from x directly
                                // then pass a pointer to y
                                // as the return value for g(X).
  return 0;
  }
----------------------------------------------------------------------

The portable application programmer can insert the `__return__' macro
instead of the `return' keyword in declarations and prepend

        #define __return__ return

for compilers which do support the proposed extension or

        #define __return__

for compilers which do not support the proposed extension.


E. Robert Tisdale <edwin@netwood.net>

Re: Named Return Value Extension Proposal

[E. Robert Tisdale]

Mike Stump wrote:

> Sounds great, but I missed the proof where you showed
> the compiler can't figure this out for itself.  :-(
> I instead favor having the compile do the hard work,
> and not require having the user try and code
> in something besides ANSI C++ in this case.

It can!
But the compiler must have already read the return statement
before it emits the code to construct x
which is something that the egcs compiler does not do.

E. Robert Tisdale <edwin@netwood.net>

Re: Named Return Value Extension Proposal

[Bill Currie]

E. Robert Tisdale wrote:
> Not quite.  The function prototype is X g0(X);
> which means that the compiler creates a temporary
> for argument X when X g0(X) is called
> then the copy constructor is called to initialize
> the return value for g0(X) before entering
> the body of the function.

Uh huh, and just why are you declaring your function as X g0(X) anyway? 
You would be much better off declaring it as X g0(const X&), which will
prevent the creation of a temporary (this is exacty what const& was
designed for, AIUI).  const & is your (and the compiler's) friend.

Bill
-- 
Leave others their otherness

Re: Named Return Value Extension Proposal

[Gabriel Dos Reis]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]

>>>>> «ERT», E Robert Tisdale <edwin@netwood.net> wrote:

ERT> My egcs-2.90.29 980515 (egcs-1.0.3 release) compiler 
ERT> does not always elide copy constructors as permitted
ERT> by the ANSI C++ standard so I propose an extension
ERT> to the C++ language similar to named return values
ERT> which the C++ programmer can use to help the compiler
ERT> identify names which reference the return value.

[...]

ERT> Function X f2(int) illustrates the named return value extension
ERT> as currently supported by my egcs compiler.  See the GCC manual at

ERT>         http://egcs.cygnus.com/onlinedocs/gcc_5.html#SEC102

ERT> The current extension is very old now and it seems unlikely to me
ERT> that it will ever be adopted as part of the ANSI C++ standard.
ERT> It solves the problem that the egcs compiler has with function X f1(int)
ERT> but the function definition is entirely incompatible with ANSI C++ and
ERT> it cannot solve the problem that the compiler has with function X g0(X).

[...]


I don't know what will be decided, but let me throw my 0.02 euros
there. I certainly don't minimize the inmportance of compiler level
optimizations. But it's my opinion that there are ISO C++ language
features--not optimizations--that need to be fixed or implemented
in the compiler. That already is a lot of work to do. I'm not
particulary interested in seeing a lot of work spent in implementing
non-stantdard features, that will probably badly interact with ISO
C++, whereas there are more fundamental topics waiting to be
addressed.

So my proposal will be: let's first catch up the Standard, then we'll
address optimizations issues.

Not just a particular optimization is _permitted_ that it means the
compiler *should* implement it, particullary when the compiler is
trying hard to get semantics right.

just my 0.02 euros.

-- Gaby

Re: Named Return Value Extension Proposal

[E. Robert Tisdale]

Mike Stump wrote:

> > Date: Mon, 22 Mar 1999 20:04:10 -0800
> > From: "E. Robert Tisdale" <edwin@netwood.net>
> > To: egcs@egcs.cygnus.com
>
> > Mike Stump wrote:
>
> > > > From: "E. Robert Tisdale" <edwin@netwood.net>
> > >
> > > > It solves the problem that the egcs compiler has with function X f1(int)
> > > > but the function definition is entirely incompatible with ANSI C++
> > >
> > > Yes.
> > >
> > > > and it cannot solve the problem that the compiler has with function
> > > > X g0(X).
> > >
> > > Why not?
> > >
> > > X g0(X x) return x(x) {
> > >   cerr << "The copy constructor may be called for g0(X)." << endl;
> > >   return x;
> > > }
> > >
> > > If this doesn't scope this way now,
> > > I don't see it as a problem to fix it so that it does,
> > > and so that the semantics of it just work the way you expect.
>
> > Not quite.  The function prototype is X g0(X); which means that the
> > compiler creates a temporary for argument X when X g0(X) is called
> > then the copy constructor is called to initialize the return value
> > for g0(X) before entering the body of the function.
>
> Maybe I am just being slow...
>
> And does your new extension fix this problem?  If it does,
> how can it, and can't the existing extension fix it the same way?
> If not, why not?  If so, I still claim they are identical
> and that your listing of g0 was unfair and misleading.

I don't know why you are confused.
Perhaps you just haven't noticed that your version

> X g0(X x) return x(x) {
>   cerr << "The copy constructor may be called for g0(X)." << endl;
>   return x;
>   }

was not defined to be inline.
Your version of X g0(X) may be a library function
and the definition may not be visible to the compiler.
If so, the compiler has only the function prototype X g0(X)
for your version which doesn't tell it that the argument
is simply a reference to the return value
but the prototype X g0(X return) for my version
would include this information
so that the calling program can call a constructor
to initialize the return value instead of the function argument.
The calling program does not actually pass an argument
to my version of X g0(X return)  because the "argument"
is actually just a reference to the return value.

Hope this helps, E. Robert Tisdale <edwin@netwood.net>

Re: Named Return Value Extension Proposal

[Mike Stump]

> Date: Mon, 22 Mar 1999 20:04:10 -0800
> From: "E. Robert Tisdale" <edwin@netwood.net>
> To: egcs@egcs.cygnus.com

> Mike Stump wrote:

> > > From: "E. Robert Tisdale" <edwin@netwood.net>
> >
> > > It solves the problem that the egcs compiler has with function X f1(int)
> > > but the function definition is entirely incompatible with ANSI C++
> >
> > Yes.
> >
> > > and it cannot solve the problem that the compiler has with function
> > > X g0(X).
> >
> > Why not?
> >
> > X g0(X x) return x(x) {
> >   cerr << "The copy constructor may be called for g0(X)." << endl;
> >   return x;
> > }
> >
> > If this doesn't scope this way now,
> > I don't see it as a problem to fix it so that it does,
> > and so that the semantics of it just work the way you expect.

> Not quite.  The function prototype is X g0(X); which means that the
> compiler creates a temporary for argument X when X g0(X) is called
> then the copy constructor is called to initialize the return value
> for g0(X) before entering the body of the function.

Maybe I am just being slow...

And does your new extension fix this problem?  If it does, how can it,
and can't the existing extension fix it the same way?  If not, why
not?  If so, I still claim they are identical and that your listing of
g0 was unfair and misleading.

Re: Named Return Value Extension Proposal

[Bill Currie]

E. Robert Tisdale wrote:
> Not quite.  The function prototype is X g0(X);
> which means that the compiler creates a temporary
> for argument X when X g0(X) is called
> then the copy constructor is called to initialize
> the return value for g0(X) before entering
> the body of the function.

Uh huh, and just why are you declaring your function as X g0(X) anyway? 
You would be much better off declaring it as X g0(const X&), which will
prevent the creation of a temporary (this is exacty what const& was
designed for, AIUI).  const & is your (and the compiler's) friend.

Bill
-- 
Leave others their otherness

Re: Named Return Value Extension Proposal

[E. Robert Tisdale]

Mike Stump wrote:

> > From: "E. Robert Tisdale" <edwin@netwood.net>
>
> > It solves the problem that the egcs compiler has with function X f1(int)
> > but the function definition is entirely incompatible with ANSI C++
>
> Yes.
>
> > and it cannot solve the problem that the compiler has with function
> > X g0(X).
>
> Why not?
>
> X g0(X x) return x(x) {
>   cerr << "The copy constructor may be called for g0(X)." << endl;
>   return x;
> }
>
> If this doesn't scope this way now,
> I don't see it as a problem to fix it so that it does,
> and so that the semantics of it just work the way you expect.

Not quite.  The function prototype is X g0(X);
which means that the compiler creates a temporary
for argument X when X g0(X) is called
then the copy constructor is called to initialize
the return value for g0(X) before entering
the body of the function.

E. Robert Tisdale <edwin@netwood.net>

Re: Named Return Value Extension Proposal

[Mike Stump]

One more thought...

> Date: Mon, 22 Mar 1999 13:07:13 -0800
> From: "E. Robert Tisdale" <edwin@netwood.net>
> To: egcs@egcs.cygnus.com

> X       g0(X x) {
>   cerr << "The copy constructor may be called for g0(X)." << endl;
>   return x;
>   }

> The current extension is very old now and it seems unlikely to me
> that it will ever be adopted as part of the ANSI C++ standard.

Right.

> It solves the problem that the egcs compiler has with function X f1(int)
> but the function definition is entirely incompatible with ANSI C++

Yes.

> and it cannot solve the problem that the compiler has with function
> X g0(X).

Why not?

X g0(X x) return x(x) {
  cerr << "The copy constructor may be called for g0(X)." << endl;
  return x;
}
  
If this doesn't scope this way now, I don't see it as a problem to fix
it so that it does, and so that the semantics of it just work the way
you expect.

> Of course, the current named value extension must be retained for
> backward compatibility but I propose a simple extension which
> permits the C++ programmer to insert the `return' keyword between
> the type and the name in a declaration to identify the name as a
> reference to the return value as shown below:

Your proposal is `better' than the original Name Value extension.  If
you proposed it 9 years ago, I would have voted that we do it instead
of the one that is in g++ now.  Now it is too late.  :-(

Because your proposal doesn't appear to bring anything new to the
table (stuff the existing extension already does), except for a
slightly more ANSI C++ feel to it.  I don't feel this slightly better
syntax is enough to want me to support the addition of an alternate
spelling of a preexisting hack.

Maybe someone will key off your pain, and devise a way to put in the
elision code that will `solve' this problem...  Make a great project
for someone that wants to play.

Re: Named Return Value Extension Proposal

[E. Robert Tisdale]

Mike Stump wrote:

> Sounds great, but I missed the proof where you showed
> the compiler can't figure this out for itself.  :-(
> I instead favor having the compile do the hard work,
> and not require having the user try and code
> in something besides ANSI C++ in this case.

It can!
But the compiler must have already read the return statement
before it emits the code to construct x
which is something that the egcs compiler does not do.

E. Robert Tisdale <edwin@netwood.net>

Re: Named Return Value Extension Proposal

[Mike Stump]

Sounds great, but I missed the proof where you showed the compiler
can't figure this out for itself.  :-( I instead favor having the
compile do the hard work, and not require having the user try and code
in something besides ANSI C++ in this case.

Re: Named Return Value Extension Proposal

[Gabriel Dos Reis]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]

>>>>> «ERT», E Robert Tisdale <edwin@netwood.net> wrote:

ERT> My egcs-2.90.29 980515 (egcs-1.0.3 release) compiler 
ERT> does not always elide copy constructors as permitted
ERT> by the ANSI C++ standard so I propose an extension
ERT> to the C++ language similar to named return values
ERT> which the C++ programmer can use to help the compiler
ERT> identify names which reference the return value.

[...]

ERT> Function X f2(int) illustrates the named return value extension
ERT> as currently supported by my egcs compiler.  See the GCC manual at

ERT>         http://egcs.cygnus.com/onlinedocs/gcc_5.html#SEC102

ERT> The current extension is very old now and it seems unlikely to me
ERT> that it will ever be adopted as part of the ANSI C++ standard.
ERT> It solves the problem that the egcs compiler has with function X f1(int)
ERT> but the function definition is entirely incompatible with ANSI C++ and
ERT> it cannot solve the problem that the compiler has with function X g0(X).

[...]


I don't know what will be decided, but let me throw my 0.02 euros
there. I certainly don't minimize the inmportance of compiler level
optimizations. But it's my opinion that there are ISO C++ language
features--not optimizations--that need to be fixed or implemented
in the compiler. That already is a lot of work to do. I'm not
particulary interested in seeing a lot of work spent in implementing
non-stantdard features, that will probably badly interact with ISO
C++, whereas there are more fundamental topics waiting to be
addressed.

So my proposal will be: let's first catch up the Standard, then we'll
address optimizations issues.

Not just a particular optimization is _permitted_ that it means the
compiler *should* implement it, particullary when the compiler is
trying hard to get semantics right.

just my 0.02 euros.

-- Gaby

Named Return Value Extension Proposal

[E. Robert Tisdale]

My egcs-2.90.29 980515 (egcs-1.0.3 release) compiler 
does not always elide copy constructors as permitted
by the ANSI C++ standard so I propose an extension
to the C++ language similar to named return values
which the C++ programmer can use to help the compiler
identify names which reference the return value.

The following test program illustrates the problem:

----------------------------------------------------------------------
// test.cc

#include<iostream>

class X {                       // a dynamic array class
  // representation
  int*  p;                      // pointer to a huge array
  int   n;                      // length of the huge array
  public:
  // constructors
  explicit
  X(int k):                     // explicit constructor definition
    p(new int[k]), n(k) { }
  X(const X& x);                // copy constructor declaration
 ~X(void) {                     // destructor definition
    if (p) delete [] p; }
  // functions
  int   length(void) const { return n; }
  // operators
  const
  int&  operator [](int j) const { return p[j]; }
  int&  operator [](int j)       { return p[j]; }
  };

X::X(const X& x):               // copy constructor definition
  p(new int[x.n]), n(x.n) {
  cerr << "The copy constructor was called!" << endl;
  for (int j = 0; j < n; j++)   // copy the array
    p[j] = x.p[j];
  }

// user defined functions

#define __return__

inline
X       f0(int n) {
  cerr << "The copy constructor may be called for f0(int)." << endl;
  return X(n);
  }
inline
X       f1(int n) {
  X __return__ x(n);
  for (int j = 0; j < n; j++)   // Modify x.
    x[j] = j;
  cerr << "The copy constructor may be called for f1(int)." << endl;
  return x ;
 }
inline
X       f2(int n) return x(n) {
  for (int j = 0; j < n; j++)   // Modify x.
    x[j] = j;
 }
inline
X       g0(X x) {
  cerr << "The copy constructor may be called for g0(X)." << endl;
  return x;
  }
inline
X       g1(const X& x) {
  cerr << "The copy constructor must be called for g1(const X&)." << endl;
  return x;
  }

int
main () {
  cerr << endl
       << "The copy constructor may be called for X x0 = f0(32);" << endl;
  X x0 = f0(32);
  cerr << endl
       << "The copy constructor may be called for X x1 = f1(32);" << endl;
  X x1 = f1(32);
  cerr << endl
       << "The copy constructor may be called for X x2 = f2(32);" << endl;
  X x2 = f2(32);
  cerr << endl
       << "The copy constructor may be called for X y0 = g0(f0(32));" << endl;
  X y0 = g0(f0(32));
  cerr << endl
       << "The copy constructor may be called for X y1 = g1(x1);" << endl;
  X y1 = g1(x1);
  cerr << endl
       << "The copy constructor must be called for X z0 = y0;" << endl;
  X z0 = y0;
  return 0;
  }
----------------------------------------------------------------------

I compiled and ran the `test' program as follows:

----------------------------------------------------------------------
$ uname -rms
Linux 2.0.36 i686
$ g++ --version
egcs-2.90.29 980515 (egcs-1.0.3 release)
$ g++ -O2 -felide-constructors -o test test.cc
./test

The copy constructor may be called for X x0 = f0(32);
The copy constructor may be called for f0(int).

The copy constructor may be called for X x1 = f1(32);
The copy constructor may be called for f1(int).
The copy constructor was called!

The copy constructor may be called for X x2 = f2(32);

The copy constructor may be called for X y0 = g0(f0(32));
The copy constructor may be called for f0(int).
The copy constructor may be called for g0(X).
The copy constructor was called!

The copy constructor may be called for X y1 = g1(x1);
The copy constructor must be called for g1(const X&).
The copy constructor was called!

The copy constructor must be called for X z0 = y0;
The copy constructor was called!
$ 
----------------------------------------------------------------------

Function X f2(int) illustrates the named return value extension
as currently supported by my egcs compiler.  See the GCC manual at

        http://egcs.cygnus.com/onlinedocs/gcc_5.html#SEC102

The current extension is very old now and it seems unlikely to me
that it will ever be adopted as part of the ANSI C++ standard.
It solves the problem that the egcs compiler has with function X f1(int)
but the function definition is entirely incompatible with ANSI C++ and
it cannot solve the problem that the compiler has with function X g0(X).

Of course, the current named value extension must be retained
for backward compatibility but I propose a simple extension
which permits the C++ programmer to insert the `return' keyword
between the type and the name in a declaration to identify the name
as a reference to the return value as shown below:

----------------------------------------------------------------------
inline
X       f(int n) {
  X return x(n);                // x is a reference to the return value.
                                // Call the X(n) constructor to initialize it.
  for (int j = 0; j < n; j++)   // Modify x.
    x[j] = j;
  return x;                     // Don't call the copy constructor!
                                // Don't call the destructor for x!
 }

inline
X       g(X return x) {         // x is a reference to the return value.
  for (int j = 0; j < n; j++)   // Modify x.
    x[j] = j;
  return x;                     // Don't call the copy constructor!
                                // Don't call the destructor for x!
  }
----------------------------------------------------------------------

The constructor which would normally be called to initialize
a temporary argument for g(X) would initialize the return value instead
even if the the return value is not a temporary:

----------------------------------------------------------------------
int
main () {
  X x(n);
  X y = g(x);                   // Don't create any temporary values.
                                // Call the copy constructor
                                // to initialize y from x directly
                                // then pass a pointer to y
                                // as the return value for g(X).
  return 0;
  }
----------------------------------------------------------------------

The portable application programmer can insert the `__return__' macro
instead of the `return' keyword in declarations and prepend

        #define __return__ return

for compilers which do support the proposed extension or

        #define __return__

for compilers which do not support the proposed extension.


E. Robert Tisdale <edwin@netwood.net>