Re: elided copy constructors

Re: elided copy constructors

[Jason Merrill]

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

 > Perhaps I shouldn't expect my C++ compiler to elide
 > the copy constructor in function g0(X) if it wasn't inline'd

You are asking it to elide copying a parameter into the return value.  How
would that work?  I suppose, as you suggest, that if g0 is inlined the
caller could figure it out and reuse the argument instead of creating the
return value.  This would require rewriting the gcc inlining code to work
at a higher level, though; inlining is currently done on the basis of RTL,
at which point we've discarded the information we would need.  We've been
talking about making his change for a while, but it's a lot of work.

 > but it I think that the C++ compiler should recognize that x in function
 > f1(int) is a reference to the return value and initialize the return
 > value with X(n) instead of creating a temporary and copying it to the
 > return value upon return from f1(int).

Similarly, this optimization is prevented by the close ties between
frontend and backend; a variable is assigned a memory location when it is
declared, and RTL is generated referring to the stack slot.  We can't
decide to make the local variable cohabit with the return slot until we're
done compiling the function, at which point it's kind of too late to go
back and change all the uses of the variable to use the new location.  This
will be greatly simplified by the planned rewrite to separate the frontends
from the backend more, and not generate RTL until the function is
complete.  I believe the Ada frontend already works this way.

 > My question is, "When should we expect the egcs compiler
 > to elide copy constructors as permitted by the standard?"

When it gets done.  I'd like to see this implemented, too, but haven't had
the time.

 > The class library need not be portable but application programmers
 > should be able to write portable applications without worrying
 > about whether copy constructors are elided or not.

??? If they're worried about portability, they should assume that copy ctors
will not be elided, and plan accordingly.

Jason

Re: elided copy constructors

[Jason Merrill]

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

 > Perhaps I shouldn't expect my C++ compiler to elide
 > the copy constructor in function g0(X) if it wasn't inline'd

You are asking it to elide copying a parameter into the return value.  How
would that work?  I suppose, as you suggest, that if g0 is inlined the
caller could figure it out and reuse the argument instead of creating the
return value.  This would require rewriting the gcc inlining code to work
at a higher level, though; inlining is currently done on the basis of RTL,
at which point we've discarded the information we would need.  We've been
talking about making his change for a while, but it's a lot of work.

 > but it I think that the C++ compiler should recognize that x in function
 > f1(int) is a reference to the return value and initialize the return
 > value with X(n) instead of creating a temporary and copying it to the
 > return value upon return from f1(int).

Similarly, this optimization is prevented by the close ties between
frontend and backend; a variable is assigned a memory location when it is
declared, and RTL is generated referring to the stack slot.  We can't
decide to make the local variable cohabit with the return slot until we're
done compiling the function, at which point it's kind of too late to go
back and change all the uses of the variable to use the new location.  This
will be greatly simplified by the planned rewrite to separate the frontends
from the backend more, and not generate RTL until the function is
complete.  I believe the Ada frontend already works this way.

 > My question is, "When should we expect the egcs compiler
 > to elide copy constructors as permitted by the standard?"

When it gets done.  I'd like to see this implemented, too, but haven't had
the time.

 > The class library need not be portable but application programmers
 > should be able to write portable applications without worrying
 > about whether copy constructors are elided or not.

??? If they're worried about portability, they should assume that copy ctors
will not be elided, and plan accordingly.

Jason

Re: elided copy constructors

[Mark Mitchell]

>>>>> "Gerald" == Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

    Gerald> At that point, please add this as a new entry to section
    Gerald> "1. General information" of our FAQ, install the patch and
    Gerald> send the corresponding diff to egsc-patches.

Here's what I put it.

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

Index: faq.html
===================================================================
RCS file: /egcs/carton/cvsfiles/wwwdocs/htdocs/faq.html,v
retrieving revision 1.116
diff -c -p -r1.116 faq.html
*** faq.html	1999/03/24 00:27:34	1.116
--- faq.html	1999/03/28 17:44:31
*************** comp.std.c++ FAQ</a>.
*** 27,32 ****
--- 27,33 ----
       <li><a href="#open-development">What is an open development model?</a>
       <li><a href="#release-fork">Releases and Forking</a>
       <li><a href="#bugreport">How to report bugs</a>
+      <li><a href="#support">How do I get a bug fixed or a feature added?</a>
    </ol> 
  
    <li><a href="#installation">Installation</a>
*************** impossible.  So, although we prefer to h
*** 283,288 ****
--- 284,319 ----
  archived, if you cannot reduce the bug report below the limit, please
  make it available for ftp or http and post the URL.
  
+ <hr>
+ <h2><a name="support">How do I get a bug fixed or a feature added?</a></h2>
+ <p>There are lots of ways to get something fixed.  The list below may be
+ incomplete, but it covers many of the common cases.  These are listed
+ roughly in order of increasing difficulty for the average GCC user,
+ meaning someone who is not skilled in the internals of GCC, and where
+ difficulty is measured in terms of the time required to fix the bug.
+ No alternative is better than any other; each has it's benefits and
+ disadvantages.
+ 
+ <ul>
+ <li>Hire someone to fix it for you.  There are various companies and
+     individuals providing support for GCC.  This alternative costs
+     money, but is relatively likely to get results.
+ 
+ <li>Report the problem to egcs-bugs and hope that someone will be kind
+     enough to fix it for you.  While this is certainly possible, and
+     sometimes happens, there is no guarantee that it will.  You should
+     not expect the same response from egcs-bugs that you would see
+     from a commercial support organization since the people who read
+     egcs-bugs, if they choose to help you, will be volunteering their
+     time.  This alternative will work best if follow the directions on
+     <a href="#bugreport">submitting bugreports</a>.
+ 
+ <li>Fix it yourself.  This alternative will probably bring results,
+     if you work hard enough, but will probably take a lot of time,
+     and, depending on the quality of your work and the perceived
+     benefits of your changes, your code may or may not ever make it
+     into an official release of EGCS.
+ </ul>
  
  <hr>
  <a name="installation"></a>

Re: elided copy constructors

[Mark Mitchell]

>>>>> "Martin" == Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

    Martin> This is how open source works: If you need a feature badly
    Martin> enough, you have the chance to do it yourself. If you
    Martin> don't, it might get never done.

I think we should probably stop giving this slightly over-simplistic
answer.  Gerald, here's what I propose as a FAQ entry.  Do you care to
install it, or will you permit me to do so, or do you reject it
altogether?

Question
--------

How do I get a problem in EGCS fixed, or a new feature added?

Answer
------

There are lots of ways to get something fixed.  The list below may be
incomplete, but it covers many of the common cases.  These are listed
roughly in order of increasing difficulty for the average GCC user,
meaning someone who is not skilled in the internals of GCC, and where
difficulty is measured in terms of the time required to fix the bug.
No alternative is better than any other; each has it's benefits and
disadvantages.

  o Hire someone to fix it for you.  There are various companies and
    individuals providing support for GCC.  This alternative costs
    money, but is relatively likely to get results.

  o Make a strong enough case that the problem is important that
    people responsible for the code in question feel guilty enough, or
    excited enough, to fix it.  Often, maintainers or authors of a
    particular section of code have enough pride in their workmanship
    to want to fix things.  This alternative will take some time and
    effort on your part, and is not guaranteed to bring results.  On
    the other hand, it is cheaper than paying someone else to do the
    work, and much easier than the next alternative.

  o Fix it yourself.  This alternative is guaranteed to bring results,
    if you work hard enough, but will probably take a lot of time,
    and, depending on the quality of your work and the perceived
    benefits of your changes, your code may or may not ever make it
    into an official release of EGCS.

------- 

BTW, it might be a nice service to all if the EGCS web-pages allowed
anybody who does provide support, whether individually or as a
company, to add a link in this FAQ entry.  I suggest listing them in
alphabetical order, and without any additional information, in the
interests of fairness.  There should be a disclaimer, saying that none
of the links are officially recommended.

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

Re: elided copy constructors

[espie]

In article < 199903192356.PAA03038@adsl-206-170-148-33.dsl.pacbell.net > you write:

>  o Fix it yourself.  This alternative is guaranteed to bring results,
>    if you work hard enough, but will probably take a lot of time,
>    and, depending on the quality of your work and the perceived
>    benefits of your changes, your code may or may not ever make it
>    into an official release of EGCS.

This is false, plain and simple.

This alternative is NOT guaranteed to bring results. You may just be stupid
enough that you won't be able to fix it, or you may have stumbled into such
an horrid bug that extensive surgery to the whole compiler may be necessary,
in which case approach two is the only one that will work.

Stating that, with hard work, anyone is able to fix anything, is just
political correctness at its worst.

(and, to be more precise about this: we all have limitations. I know 
I do have limitations, which have nothing to do with time and hard work... 
there is stuff I can do, and there is stuff I never will be able to)

Re: elided copy constructors

[Mark Mitchell]

>>>>> "Martin" == Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

    Martin> I think here lies a terrible danger. IMHO, the only option
    Martin> that is guaranteed to work is option 1, and even then only
    Martin> if the amount of money is good enough so that the right
    Martin> people get involved.

Let's not over-analyze.  I've received enough criticism about the way
I wrote option two (asking us nicely to fix it) that I've rewritten
that entry, to get a different tone:

  o Report the problem to egcs-bugs and hope that someone will be kind
    enough to fix it for you.  While this is certainly possible, and
    sometimes happens, there is no guarantee that it will.  You should
    not expect the same response from egcs-bugs that you would see
    from a commercial support organization since the people who read
    egcs-bugs, if they choose to help you, will be volunteering their
    time.  This alternative will work best if you can make your bug
    report as easy to read as possible.  (See <how to write a bug
    report FAQ entry>.)

But, of course, different things will work for different people.  My
goal was to produce a FAQ entry that would give people a clue about
their options, and I still think I succeeded.  I, for one, know that I
have fixed bugs in my code simply out of a feeling of responsibilty;
Martin, I know that you have done the same.  On the other hand, some
of us are both reasonably competent compiler programmers; most people
are probably not willing to dive too far into GCC.  Marc Espie
criticized me for encouraging people to do this, saying that some
people are just unable.  That may or may not be true, but I don't
think this is the forum for that discussion.  People can make that
judgement for themselves; people who know nothing of compilers are
unlikely to dive right in just because I said it's possible.

I think we agree that the three alternatives I listed are the obvious
choices; let's get them in, as FAQ entry, so that we have something to
point "When will this get done?" questions at that's a bit more polite
than just "When you do it yourself!".  Also, some people may not know
that commercial support is available, or what alternatives exist in
that arena; we would all benefit if more people utilized this option
in that we would see more improvements to GCC.

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

Re: elided copy constructors

[Timmy Mulligins]

>From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
>To: edwin@netwood.net
>CC: egcs@egcs.cygnus.com
>Subject: Re: elided copy constructors
>Date: Sat, 20 Mar 1999 00:13:03 +0100
>MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko")
From egcs-return-4298-picard1981=hotmail.com@egcs.cygnus.com Fri Mar 19 
15:19:31 1999
>Received: (qmail 28564 invoked by alias); 19 Mar 1999 23:18:40 -0000
>Mailing-List: contact egcs-help@egcs.cygnus.com; run by ezmlm
>Precedence: bulk
>Sender: owner-egcs@egcs.cygnus.com
>Delivered-To: mailing list egcs@egcs.cygnus.com
>Received: (qmail 28550 invoked from network); 19 Mar 1999 23:18:37 
-0000
>Received: from mail.cs.tu-berlin.de (root@130.149.17.13)by 
egcs.cygnus.com with SMTP; 19 Mar 1999 23:18:37 -0000
>Received: from mira.isdn.cs.tu-berlin.de (mira.isdn.cs.tu-berlin.de 
[130.149.221.146])by mail.cs.tu-berlin.de (8.9.1/8.9.1) with ESMTP id 
AAA06159;Sat, 20 Mar 1999 00:13:58 +0100 (MET)
>Received: (from martin@localhost)by mira.isdn.cs.tu-berlin.de 
(8.8.7/8.8.7) id AAA00798;Sat, 20 Mar 1999 00:13:03 +0100
>Message-Id: < 199903192313.AAA00798@mira.isdn.cs.tu-berlin.de >
>X-Authentication-Warning: mira.isdn.cs.tu-berlin.de: martin set sender 
to martin@mira.isdn.cs.tu-berlin.de using -f
>In-reply-to: < 36F2CDC1.8B4FEC4A@netwood.net > (edwin@netwood.net)
>References:  < 36F2CDC1.8B4FEC4A@netwood.net >
>User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.3.92 
(i586-pc-linux-gnu) MULE/4.0 (HANANOEN)
>
>> My question is, "When should we expect the egcs compiler
>> to elide copy constructors as permitted by the standard?"
>
>Well, the short (and AFAIK the only correct) answer is: when somebody
>contributes the code.
>
>This is how open source works: If you need a feature badly enough, you
>have the chance to do it yourself. If you don't, it might get never
>done.
Sounds like the maintainers might be spending all of their time fixing 
errors and ways to do all the wacky things that people want. Results?
Broken compiler syndrome. Incompatabilities.
Almost safer to let Homer Simpson do it.
Get Your Private, Free Email at http://www.hotmail.com

Re: elided copy constructors

[Martin v. Loewis]

[1 hire somebody]
[2 ask somebody to do it for free]
[3 do it yourself]

> This alternative is NOT guaranteed to bring results. You may just be stupid
> enough that you won't be able to fix it, or you may have stumbled into such
> an horrid bug that extensive surgery to the whole compiler may be necessary,
> in which case approach two is the only one that will work.

I think here lies a terrible danger. IMHO, the only option that is
guaranteed to work is option 1, and even then only if the amount of
money is good enough so that the right people get involved.

Option 2, typically, does *not* work, with the single exception that
somebody didn't fix a bug because she was not aware of it. In most
cases (especially long-standing bugs and missing features),
maintainers are well-aware that there is that problem, and think that
they fix it when they get to it. It doesn't get done because they
never get to it.

So, option 3 always worked for me. I don't remember a case where
option 2 actually worked - except when the person I asked heard of it
for the first time, and fixed it right-away.

Regards,
Martin

Re: elided copy constructors

[Gerald Pfeifer]

On Sun, 28 Mar 1999, Mark Mitchell wrote:
> Here's what I put it.

Thanks!  I have fixed a small "typo" and made the second option a bit
more optimistic, according to my personal experience:

  alphard[56]:~% ls -la Bugreports/egcs* | wc -l
      55
  alphard[57]:~% ls -la Bugreports/egcs* | grep -v fixed | wc -l
       8

I.e., only 8 bugs out of 55 I have reported have not been fixed yet. :-)

Gerald

Index: faq.html
===================================================================
RCS file: /egcs/carton/cvsfiles/wwwdocs/htdocs/faq.html,v
retrieving revision 1.117
diff -c -3 -p -r1.117 faq.html
*** faq.html	1999/03/28 09:45:26	1.117
--- faq.html	1999/03/29 20:46:01
*************** disadvantages.
*** 301,312 ****
  
  <li>Report the problem to egcs-bugs and hope that someone will be kind
      enough to fix it for you.  While this is certainly possible, and
!     sometimes happens, there is no guarantee that it will.  You should
      not expect the same response from egcs-bugs that you would see
      from a commercial support organization since the people who read
      egcs-bugs, if they choose to help you, will be volunteering their
!     time.  This alternative will work best if follow the directions on
!     <a href="#bugreport">submitting bugreports</a>.
  
  <li>Fix it yourself.  This alternative will probably bring results,
      if you work hard enough, but will probably take a lot of time,
--- 301,312 ----
  
  <li>Report the problem to egcs-bugs and hope that someone will be kind
      enough to fix it for you.  While this is certainly possible, and
!     often happens, there is no guarantee that it will.  You should
      not expect the same response from egcs-bugs that you would see
      from a commercial support organization since the people who read
      egcs-bugs, if they choose to help you, will be volunteering their
!     time.  This alternative will work best if you follow the directions
!     on <a href="#bugreport">submitting bugreports</a>.
  
  <li>Fix it yourself.  This alternative will probably bring results,
      if you work hard enough, but will probably take a lot of time,
*************** only be necessary if you are building an
*** 1168,1174 ****
  
  
  <p><a href="index.html">Return to the EGCS home page</a>
! <p><i>Last modified:  March 23, 1999</i>
  
  <!--#include virtual="/glimpsebox.html"-->
  </body>
--- 1168,1174 ----
  
  
  <p><a href="index.html">Return to the EGCS home page</a>
! <p><i>Last modified:  March 29, 1999</i>
  
  <!--#include virtual="/glimpsebox.html"-->
  </body>

Re: elided copy constructors

[Martin v. Loewis]

> My question is, "When should we expect the egcs compiler
> to elide copy constructors as permitted by the standard?"

Well, the short (and AFAIK the only correct) answer is: when somebody
contributes the code.

This is how open source works: If you need a feature badly enough, you
have the chance to do it yourself. If you don't, it might get never
done.

Regards,
Martin

elided copy constructors

[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 must devise a workaround
to void a costly copy of doomed objects which
won't be referenced again until they are destroyed.
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
  // constructors
  X(int* q, int k):             // private constructor definition
    p(q), n(k) { }
  public:
  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; }
  friend                        // salvage a doomed array
  X     salvage(X& x) { int* q = x.p; x.p = 0; return X(q, x.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 salvage(x) x
#define return(x) return salvage(x)

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     x(n);
  for (int j = 0; j < n; j++)   // Initialize x.
    x[j] = j;
  cerr << "The copy constructor may be called for f1(int)." << endl;
  return(x);
 }
inline
X       g0(X x) {
  cerr << "The copy constructor may be called for g0(X)." << endl;
  return salvage(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 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 `test' 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 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!
$ 
----------------------------------------------------------------------

After editing the `test.cc' source file
to comment out the first C preprocessor macro definition

// #define salvage(x) x

I compiled and ran `test' again as follows:

----------------------------------------------------------------------
$ 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 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 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!
[edwin@localhost svmt]$ 
----------------------------------------------------------------------

Perhaps I shouldn't expect my C++ compiler to elide
the copy constructor in function g0(X) if it wasn't inline'd
but it I think that the C++ compiler should recognize
that x in function f1(int) is a reference to the return value
and initialize the return value with X(n)
instead of creating a temporary and copying it
to the return value upon return from f1(int).

My question is, "When should we expect the egcs compiler
to elide copy constructors as permitted by the standard?"

Meanwhile, I am interested in comments and suggestions
concerning workarounds.

Yes, I really do need to return by value.
No, I really don't want to do reference counting.
I am developing class libraries for application programmers

        http://www.netwood.net/~edwin/svmt/

The class library need not be portable but application programmers
should be able to write portable applications without worrying
about whether copy constructors are elided or not.

Thanks in advance, E. Robert Tisdale <edwin@netwood.net>

Re: elided copy constructors

[Tim Hollebeek]

Mark Mitchell writes ...
> 
>   o Make a strong enough case that the problem is important that
>     people responsible for the code in question feel guilty enough, or
>     excited enough, to fix it.  Often, maintainers or authors of a
>     particular section of code have enough pride in their workmanship
>     to want to fix things.  This alternative will take some time and
>     effort on your part, and is not guaranteed to bring results.  On
>     the other hand, it is cheaper than paying someone else to do the
>     work, and much easier than the next alternative.

Perhaps it would not be unwise to mention that this is more likely to
happen if you "make people feel guilty" in a polite way.

---------------------------------------------------------------------------
Tim Hollebeek                           | "Everything above is a true
email: tim@wfn-shop.princeton.edu       |  statement, for sufficiently
URL: http://wfn-shop.princeton.edu/~tim |  false values of true."

Re: elided copy constructors

[Gerald Pfeifer]

On Fri, 19 Mar 1999, Mark Mitchell wrote:
> Gerald, here's what I propose as a FAQ entry.  Do you care to
> install it, or will you permit me to do so, or do you reject it
> altogether?

I agree that this is a useful addition to our FAQ, but I also noticed
that it has started a thread of its own, so I'd like to wait a couple of
days resp. until the discussion has settled.

> How do I get a problem in EGCS fixed, or a new feature added?

At that point, please add this as a new entry to section "1. General
information" of our FAQ, install the patch and send the corresponding
diff to egsc-patches.

Thanks!
Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: elided copy constructors

[craig]

[...]
>I wrote option two (asking us nicely to fix it) that I've rewritten
>that entry, to get a different tone:

Thanks to Mark and others for working on this!!

        tq vm, (burley)

Re: elided copy constructors

[Gerald Pfeifer]

On Sun, 28 Mar 1999, Mark Mitchell wrote:
> Here's what I put it.

Thanks!  I have fixed a small "typo" and made the second option a bit
more optimistic, according to my personal experience:

  alphard[56]:~% ls -la Bugreports/egcs* | wc -l
      55
  alphard[57]:~% ls -la Bugreports/egcs* | grep -v fixed | wc -l
       8

I.e., only 8 bugs out of 55 I have reported have not been fixed yet. :-)

Gerald

Index: faq.html
===================================================================
RCS file: /egcs/carton/cvsfiles/wwwdocs/htdocs/faq.html,v
retrieving revision 1.117
diff -c -3 -p -r1.117 faq.html
*** faq.html	1999/03/28 09:45:26	1.117
--- faq.html	1999/03/29 20:46:01
*************** disadvantages.
*** 301,312 ****
  
  <li>Report the problem to egcs-bugs and hope that someone will be kind
      enough to fix it for you.  While this is certainly possible, and
!     sometimes happens, there is no guarantee that it will.  You should
      not expect the same response from egcs-bugs that you would see
      from a commercial support organization since the people who read
      egcs-bugs, if they choose to help you, will be volunteering their
!     time.  This alternative will work best if follow the directions on
!     <a href="#bugreport">submitting bugreports</a>.
  
  <li>Fix it yourself.  This alternative will probably bring results,
      if you work hard enough, but will probably take a lot of time,
--- 301,312 ----
  
  <li>Report the problem to egcs-bugs and hope that someone will be kind
      enough to fix it for you.  While this is certainly possible, and
!     often happens, there is no guarantee that it will.  You should
      not expect the same response from egcs-bugs that you would see
      from a commercial support organization since the people who read
      egcs-bugs, if they choose to help you, will be volunteering their
!     time.  This alternative will work best if you follow the directions
!     on <a href="#bugreport">submitting bugreports</a>.
  
  <li>Fix it yourself.  This alternative will probably bring results,
      if you work hard enough, but will probably take a lot of time,
*************** only be necessary if you are building an
*** 1168,1174 ****
  
  
  <p><a href="index.html">Return to the EGCS home page</a>
! <p><i>Last modified:  March 23, 1999</i>
  
  <!--#include virtual="/glimpsebox.html"-->
  </body>
--- 1168,1174 ----
  
  
  <p><a href="index.html">Return to the EGCS home page</a>
! <p><i>Last modified:  March 29, 1999</i>
  
  <!--#include virtual="/glimpsebox.html"-->
  </body>

Re: elided copy constructors

[Mark Mitchell]

>>>>> "Gerald" == Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

    Gerald> At that point, please add this as a new entry to section
    Gerald> "1. General information" of our FAQ, install the patch and
    Gerald> send the corresponding diff to egsc-patches.

Here's what I put it.

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

Index: faq.html
===================================================================
RCS file: /egcs/carton/cvsfiles/wwwdocs/htdocs/faq.html,v
retrieving revision 1.116
diff -c -p -r1.116 faq.html
*** faq.html	1999/03/24 00:27:34	1.116
--- faq.html	1999/03/28 17:44:31
*************** comp.std.c++ FAQ</a>.
*** 27,32 ****
--- 27,33 ----
       <li><a href="#open-development">What is an open development model?</a>
       <li><a href="#release-fork">Releases and Forking</a>
       <li><a href="#bugreport">How to report bugs</a>
+      <li><a href="#support">How do I get a bug fixed or a feature added?</a>
    </ol> 
  
    <li><a href="#installation">Installation</a>
*************** impossible.  So, although we prefer to h
*** 283,288 ****
--- 284,319 ----
  archived, if you cannot reduce the bug report below the limit, please
  make it available for ftp or http and post the URL.
  
+ <hr>
+ <h2><a name="support">How do I get a bug fixed or a feature added?</a></h2>
+ <p>There are lots of ways to get something fixed.  The list below may be
+ incomplete, but it covers many of the common cases.  These are listed
+ roughly in order of increasing difficulty for the average GCC user,
+ meaning someone who is not skilled in the internals of GCC, and where
+ difficulty is measured in terms of the time required to fix the bug.
+ No alternative is better than any other; each has it's benefits and
+ disadvantages.
+ 
+ <ul>
+ <li>Hire someone to fix it for you.  There are various companies and
+     individuals providing support for GCC.  This alternative costs
+     money, but is relatively likely to get results.
+ 
+ <li>Report the problem to egcs-bugs and hope that someone will be kind
+     enough to fix it for you.  While this is certainly possible, and
+     sometimes happens, there is no guarantee that it will.  You should
+     not expect the same response from egcs-bugs that you would see
+     from a commercial support organization since the people who read
+     egcs-bugs, if they choose to help you, will be volunteering their
+     time.  This alternative will work best if follow the directions on
+     <a href="#bugreport">submitting bugreports</a>.
+ 
+ <li>Fix it yourself.  This alternative will probably bring results,
+     if you work hard enough, but will probably take a lot of time,
+     and, depending on the quality of your work and the perceived
+     benefits of your changes, your code may or may not ever make it
+     into an official release of EGCS.
+ </ul>
  
  <hr>
  <a name="installation"></a>

Re: elided copy constructors

[Gerald Pfeifer]

On Fri, 19 Mar 1999, Mark Mitchell wrote:
> Gerald, here's what I propose as a FAQ entry.  Do you care to
> install it, or will you permit me to do so, or do you reject it
> altogether?

I agree that this is a useful addition to our FAQ, but I also noticed
that it has started a thread of its own, so I'd like to wait a couple of
days resp. until the discussion has settled.

> How do I get a problem in EGCS fixed, or a new feature added?

At that point, please add this as a new entry to section "1. General
information" of our FAQ, install the patch and send the corresponding
diff to egsc-patches.

Thanks!
Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: elided copy constructors

[craig]

[...]
>I wrote option two (asking us nicely to fix it) that I've rewritten
>that entry, to get a different tone:

Thanks to Mark and others for working on this!!

        tq vm, (burley)

Re: elided copy constructors

[Mark Mitchell]

>>>>> "Martin" == Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

    Martin> I think here lies a terrible danger. IMHO, the only option
    Martin> that is guaranteed to work is option 1, and even then only
    Martin> if the amount of money is good enough so that the right
    Martin> people get involved.

Let's not over-analyze.  I've received enough criticism about the way
I wrote option two (asking us nicely to fix it) that I've rewritten
that entry, to get a different tone:

  o Report the problem to egcs-bugs and hope that someone will be kind
    enough to fix it for you.  While this is certainly possible, and
    sometimes happens, there is no guarantee that it will.  You should
    not expect the same response from egcs-bugs that you would see
    from a commercial support organization since the people who read
    egcs-bugs, if they choose to help you, will be volunteering their
    time.  This alternative will work best if you can make your bug
    report as easy to read as possible.  (See <how to write a bug
    report FAQ entry>.)

But, of course, different things will work for different people.  My
goal was to produce a FAQ entry that would give people a clue about
their options, and I still think I succeeded.  I, for one, know that I
have fixed bugs in my code simply out of a feeling of responsibilty;
Martin, I know that you have done the same.  On the other hand, some
of us are both reasonably competent compiler programmers; most people
are probably not willing to dive too far into GCC.  Marc Espie
criticized me for encouraging people to do this, saying that some
people are just unable.  That may or may not be true, but I don't
think this is the forum for that discussion.  People can make that
judgement for themselves; people who know nothing of compilers are
unlikely to dive right in just because I said it's possible.

I think we agree that the three alternatives I listed are the obvious
choices; let's get them in, as FAQ entry, so that we have something to
point "When will this get done?" questions at that's a bit more polite
than just "When you do it yourself!".  Also, some people may not know
that commercial support is available, or what alternatives exist in
that arena; we would all benefit if more people utilized this option
in that we would see more improvements to GCC.

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

Re: elided copy constructors

[Martin v. Loewis]

[1 hire somebody]
[2 ask somebody to do it for free]
[3 do it yourself]

> This alternative is NOT guaranteed to bring results. You may just be stupid
> enough that you won't be able to fix it, or you may have stumbled into such
> an horrid bug that extensive surgery to the whole compiler may be necessary,
> in which case approach two is the only one that will work.

I think here lies a terrible danger. IMHO, the only option that is
guaranteed to work is option 1, and even then only if the amount of
money is good enough so that the right people get involved.

Option 2, typically, does *not* work, with the single exception that
somebody didn't fix a bug because she was not aware of it. In most
cases (especially long-standing bugs and missing features),
maintainers are well-aware that there is that problem, and think that
they fix it when they get to it. It doesn't get done because they
never get to it.

So, option 3 always worked for me. I don't remember a case where
option 2 actually worked - except when the person I asked heard of it
for the first time, and fixed it right-away.

Regards,
Martin

Re: elided copy constructors

[espie]

In article < 199903192356.PAA03038@adsl-206-170-148-33.dsl.pacbell.net > you write:

>  o Fix it yourself.  This alternative is guaranteed to bring results,
>    if you work hard enough, but will probably take a lot of time,
>    and, depending on the quality of your work and the perceived
>    benefits of your changes, your code may or may not ever make it
>    into an official release of EGCS.

This is false, plain and simple.

This alternative is NOT guaranteed to bring results. You may just be stupid
enough that you won't be able to fix it, or you may have stumbled into such
an horrid bug that extensive surgery to the whole compiler may be necessary,
in which case approach two is the only one that will work.

Stating that, with hard work, anyone is able to fix anything, is just
political correctness at its worst.

(and, to be more precise about this: we all have limitations. I know 
I do have limitations, which have nothing to do with time and hard work... 
there is stuff I can do, and there is stuff I never will be able to)

Re: elided copy constructors

[Tim Hollebeek]

Mark Mitchell writes ...
> 
>   o Make a strong enough case that the problem is important that
>     people responsible for the code in question feel guilty enough, or
>     excited enough, to fix it.  Often, maintainers or authors of a
>     particular section of code have enough pride in their workmanship
>     to want to fix things.  This alternative will take some time and
>     effort on your part, and is not guaranteed to bring results.  On
>     the other hand, it is cheaper than paying someone else to do the
>     work, and much easier than the next alternative.

Perhaps it would not be unwise to mention that this is more likely to
happen if you "make people feel guilty" in a polite way.

---------------------------------------------------------------------------
Tim Hollebeek                           | "Everything above is a true
email: tim@wfn-shop.princeton.edu       |  statement, for sufficiently
URL: http://wfn-shop.princeton.edu/~tim |  false values of true."

Re: elided copy constructors

[Mark Mitchell]

>>>>> "Martin" == Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

    Martin> This is how open source works: If you need a feature badly
    Martin> enough, you have the chance to do it yourself. If you
    Martin> don't, it might get never done.

I think we should probably stop giving this slightly over-simplistic
answer.  Gerald, here's what I propose as a FAQ entry.  Do you care to
install it, or will you permit me to do so, or do you reject it
altogether?

Question
--------

How do I get a problem in EGCS fixed, or a new feature added?

Answer
------

There are lots of ways to get something fixed.  The list below may be
incomplete, but it covers many of the common cases.  These are listed
roughly in order of increasing difficulty for the average GCC user,
meaning someone who is not skilled in the internals of GCC, and where
difficulty is measured in terms of the time required to fix the bug.
No alternative is better than any other; each has it's benefits and
disadvantages.

  o Hire someone to fix it for you.  There are various companies and
    individuals providing support for GCC.  This alternative costs
    money, but is relatively likely to get results.

  o Make a strong enough case that the problem is important that
    people responsible for the code in question feel guilty enough, or
    excited enough, to fix it.  Often, maintainers or authors of a
    particular section of code have enough pride in their workmanship
    to want to fix things.  This alternative will take some time and
    effort on your part, and is not guaranteed to bring results.  On
    the other hand, it is cheaper than paying someone else to do the
    work, and much easier than the next alternative.

  o Fix it yourself.  This alternative is guaranteed to bring results,
    if you work hard enough, but will probably take a lot of time,
    and, depending on the quality of your work and the perceived
    benefits of your changes, your code may or may not ever make it
    into an official release of EGCS.

------- 

BTW, it might be a nice service to all if the EGCS web-pages allowed
anybody who does provide support, whether individually or as a
company, to add a link in this FAQ entry.  I suggest listing them in
alphabetical order, and without any additional information, in the
interests of fairness.  There should be a disclaimer, saying that none
of the links are officially recommended.

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

Re: elided copy constructors

[Timmy Mulligins]

>From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
>To: edwin@netwood.net
>CC: egcs@egcs.cygnus.com
>Subject: Re: elided copy constructors
>Date: Sat, 20 Mar 1999 00:13:03 +0100
>MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko")
From egcs-return-4298-picard1981=hotmail.com@egcs.cygnus.com Fri Mar 19 
15:19:31 1999
>Received: (qmail 28564 invoked by alias); 19 Mar 1999 23:18:40 -0000
>Mailing-List: contact egcs-help@egcs.cygnus.com; run by ezmlm
>Precedence: bulk
>Sender: owner-egcs@egcs.cygnus.com
>Delivered-To: mailing list egcs@egcs.cygnus.com
>Received: (qmail 28550 invoked from network); 19 Mar 1999 23:18:37 
-0000
>Received: from mail.cs.tu-berlin.de (root@130.149.17.13)by 
egcs.cygnus.com with SMTP; 19 Mar 1999 23:18:37 -0000
>Received: from mira.isdn.cs.tu-berlin.de (mira.isdn.cs.tu-berlin.de 
[130.149.221.146])by mail.cs.tu-berlin.de (8.9.1/8.9.1) with ESMTP id 
AAA06159;Sat, 20 Mar 1999 00:13:58 +0100 (MET)
>Received: (from martin@localhost)by mira.isdn.cs.tu-berlin.de 
(8.8.7/8.8.7) id AAA00798;Sat, 20 Mar 1999 00:13:03 +0100
>Message-Id: < 199903192313.AAA00798@mira.isdn.cs.tu-berlin.de >
>X-Authentication-Warning: mira.isdn.cs.tu-berlin.de: martin set sender 
to martin@mira.isdn.cs.tu-berlin.de using -f
>In-reply-to: < 36F2CDC1.8B4FEC4A@netwood.net > (edwin@netwood.net)
>References:  < 36F2CDC1.8B4FEC4A@netwood.net >
>User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.3.92 
(i586-pc-linux-gnu) MULE/4.0 (HANANOEN)
>
>> My question is, "When should we expect the egcs compiler
>> to elide copy constructors as permitted by the standard?"
>
>Well, the short (and AFAIK the only correct) answer is: when somebody
>contributes the code.
>
>This is how open source works: If you need a feature badly enough, you
>have the chance to do it yourself. If you don't, it might get never
>done.
Sounds like the maintainers might be spending all of their time fixing 
errors and ways to do all the wacky things that people want. Results?
Broken compiler syndrome. Incompatabilities.
Almost safer to let Homer Simpson do it.
Get Your Private, Free Email at http://www.hotmail.com

Re: elided copy constructors

[Martin v. Loewis]

> My question is, "When should we expect the egcs compiler
> to elide copy constructors as permitted by the standard?"

Well, the short (and AFAIK the only correct) answer is: when somebody
contributes the code.

This is how open source works: If you need a feature badly enough, you
have the chance to do it yourself. If you don't, it might get never
done.

Regards,
Martin

elided copy constructors

[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 must devise a workaround
to void a costly copy of doomed objects which
won't be referenced again until they are destroyed.
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
  // constructors
  X(int* q, int k):             // private constructor definition
    p(q), n(k) { }
  public:
  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; }
  friend                        // salvage a doomed array
  X     salvage(X& x) { int* q = x.p; x.p = 0; return X(q, x.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 salvage(x) x
#define return(x) return salvage(x)

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     x(n);
  for (int j = 0; j < n; j++)   // Initialize x.
    x[j] = j;
  cerr << "The copy constructor may be called for f1(int)." << endl;
  return(x);
 }
inline
X       g0(X x) {
  cerr << "The copy constructor may be called for g0(X)." << endl;
  return salvage(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 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 `test' 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 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!
$ 
----------------------------------------------------------------------

After editing the `test.cc' source file
to comment out the first C preprocessor macro definition

// #define salvage(x) x

I compiled and ran `test' again as follows:

----------------------------------------------------------------------
$ 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 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 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!
[edwin@localhost svmt]$ 
----------------------------------------------------------------------

Perhaps I shouldn't expect my C++ compiler to elide
the copy constructor in function g0(X) if it wasn't inline'd
but it I think that the C++ compiler should recognize
that x in function f1(int) is a reference to the return value
and initialize the return value with X(n)
instead of creating a temporary and copying it
to the return value upon return from f1(int).

My question is, "When should we expect the egcs compiler
to elide copy constructors as permitted by the standard?"

Meanwhile, I am interested in comments and suggestions
concerning workarounds.

Yes, I really do need to return by value.
No, I really don't want to do reference counting.
I am developing class libraries for application programmers

        http://www.netwood.net/~edwin/svmt/

The class library need not be portable but application programmers
should be able to write portable applications without worrying
about whether copy constructors are elided or not.

Thanks in advance, E. Robert Tisdale <edwin@netwood.net>