elided copy constructors

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

[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

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

[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

[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

[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

[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

[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

[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

[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

[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

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

[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/

New webpage? Providing egcs support

[Gerald Pfeifer]

[ I have made this a new thread. ]

On Fri, 19 Mar 1999, Mark Mitchell wrote:
> 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.

Personally, I won't object such a list, however I believe this is
something that should be approved by Jeff resp. the Steering Committee
first.

Isn't there also a list of people providing support which is maintained by
the FSF for similiar cases?

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

Re: New webpage? Providing egcs support

[Mark Mitchell]

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

    Gerald> Personally, I won't object such a list, however I believe
    Gerald> this is something that should be approved by Jeff
    Gerald> resp. the Steering Committee first.

Agreed.

    Gerald> Isn't there also a list of people providing support which
    Gerald> is maintained by the FSF for similiar cases?

Yes, the SERVICES file.  It is not particularly easily accessible to
people who have done a binary (e.g., RPM) installation.  It also
contains entries for entities who provide support for other products.
For example, GNU Emacs hackers are listed there.  It might be
reasonable to initially construct the list from the FAQ entry by
culling entries from SERVICES, but I don't think SERVICES itself
belongs in the FAQ entry.  IMO, just a list of hyperlinks to
web-pages/email-addresses would be most useful.

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

Re: New webpage? Providing egcs support

[Mark Mitchell]

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

    Gerald> Personally, I won't object such a list, however I believe
    Gerald> this is something that should be approved by Jeff
    Gerald> resp. the Steering Committee first.

Agreed.

    Gerald> Isn't there also a list of people providing support which
    Gerald> is maintained by the FSF for similiar cases?

Yes, the SERVICES file.  It is not particularly easily accessible to
people who have done a binary (e.g., RPM) installation.  It also
contains entries for entities who provide support for other products.
For example, GNU Emacs hackers are listed there.  It might be
reasonable to initially construct the list from the FAQ entry by
culling entries from SERVICES, but I don't think SERVICES itself
belongs in the FAQ entry.  IMO, just a list of hyperlinks to
web-pages/email-addresses would be most useful.

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

Re: New webpage? Providing egcs support

[Jeffrey A Law]

  In message < Pine.GSO.4.10.9903211733410.1651-100000@markab.dbai.tuwien.ac.at >
you write:
  > Personally, I won't object such a list, however I believe this is
  > something that should be approved by Jeff resp. the Steering Committee
  > first.
  > 
  > Isn't there also a list of people providing support which is maintained by
  > the FSF for similiar cases?
I think it's reasonable to put a copy of "SERVICES" online via a cgi script
to extract it out of the CVS tree.

I don't think we should try to do anything more than that right now.

jeff

Re: New webpage? Providing egcs support

[Jeffrey A Law]

  In message < Pine.GSO.4.10.9903211733410.1651-100000@markab.dbai.tuwien.ac.at >
you write:
  > Personally, I won't object such a list, however I believe this is
  > something that should be approved by Jeff resp. the Steering Committee
  > first.
  > 
  > Isn't there also a list of people providing support which is maintained by
  > the FSF for similiar cases?
I think it's reasonable to put a copy of "SERVICES" online via a cgi script
to extract it out of the CVS tree.

I don't think we should try to do anything more than that right now.

jeff

New webpage? Providing egcs support

[Gerald Pfeifer]

[ I have made this a new thread. ]

On Fri, 19 Mar 1999, Mark Mitchell wrote:
> 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.

Personally, I won't object such a list, however I believe this is
something that should be approved by Jeff resp. the Steering Committee
first.

Isn't there also a list of people providing support which is maintained by
the FSF for similiar cases?

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

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

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