public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: Named Return Value Extension Proposal
@ 1999-03-22 19:37 Mike Stump
  1999-03-22 20:07 ` E. Robert Tisdale
  1999-03-31 23:46 ` Mike Stump
  0 siblings, 2 replies; 26+ messages in thread
From: Mike Stump @ 1999-03-22 19:37 UTC (permalink / raw)
  To: edwin, egcs

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.

^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: Named Return Value Extension Proposal
@ 1999-03-23  6:43 Mike Stump
  1999-03-23  9:00 ` E. Robert Tisdale
  1999-03-31 23:46 ` Mike Stump
  0 siblings, 2 replies; 26+ messages in thread
From: Mike Stump @ 1999-03-23  6:43 UTC (permalink / raw)
  To: edwin, egcs

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

^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: Named Return Value Extension Proposal
@ 1999-03-22 18:58 E. Robert Tisdale
       [not found] ` < 36F7029D.F0EE48E8@netwood.net >
                   ` (2 more replies)
  0 siblings, 3 replies; 26+ messages in thread
From: E. Robert Tisdale @ 1999-03-22 18:58 UTC (permalink / raw)
  To: egcs

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>

^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: Named Return Value Extension Proposal
@ 1999-03-22 18:57 Mike Stump
  1999-03-22 19:08 ` E. Robert Tisdale
  1999-03-31 23:46 ` Mike Stump
  0 siblings, 2 replies; 26+ messages in thread
From: Mike Stump @ 1999-03-22 18:57 UTC (permalink / raw)
  To: edwin, egcs

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.

^ permalink raw reply	[flat|nested] 26+ messages in thread
* Named Return Value Extension Proposal
@ 1999-03-22 13:10 E. Robert Tisdale
  1999-03-22 16:59 ` Gabriel Dos Reis
  1999-03-31 23:46 ` E. Robert Tisdale
  0 siblings, 2 replies; 26+ messages in thread
From: E. Robert Tisdale @ 1999-03-22 13:10 UTC (permalink / raw)
  To: egcs

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>

^ permalink raw reply	[flat|nested] 26+ messages in thread
end of thread, other threads:[~1999-03-31 23:46 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-03-22 19:37 Named Return Value Extension Proposal Mike Stump
1999-03-22 20:07 ` E. Robert Tisdale
1999-03-22 21:14   ` Bill Currie
1999-03-31 23:46     ` Bill Currie
1999-03-31 23:46   ` E. Robert Tisdale
1999-03-31 23:46 ` Mike Stump
  -- strict thread matches above, loose matches on Subject: below --
1999-03-23  6:43 Mike Stump
1999-03-23  9:00 ` E. Robert Tisdale
1999-03-31 23:46   ` E. Robert Tisdale
1999-03-31 23:46 ` Mike Stump
1999-03-22 18:58 E. Robert Tisdale
     [not found] ` < 36F7029D.F0EE48E8@netwood.net >
1999-03-22 19:14   ` Mark Mitchell
     [not found]     ` < 199903230316.TAA05276@adsl-206-170-148-33.dsl.pacbell.net >
1999-03-23  1:05       ` Martin v. Loewis
1999-03-31 23:46         ` Martin v. Loewis
1999-03-31 23:46     ` Mark Mitchell
1999-03-22 19:39 ` Gabriel Dos Reis
1999-03-31 23:46   ` Gabriel Dos Reis
1999-03-31 23:46 ` E. Robert Tisdale
1999-03-22 18:57 Mike Stump
1999-03-22 19:08 ` E. Robert Tisdale
1999-03-31 23:46   ` E. Robert Tisdale
1999-03-31 23:46 ` Mike Stump
1999-03-22 13:10 E. Robert Tisdale
1999-03-22 16:59 ` Gabriel Dos Reis
1999-03-31 23:46   ` Gabriel Dos Reis
1999-03-31 23:46 ` E. Robert Tisdale

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).