Regarding the eliding of copy constructors, John Max Skaller wrote:

>        Completely irrelevent. The compiler is permitted to elide
>the copy constructor anyhow. If this changes the observable behaviour
>of you program it's your own fault that your code is not deterministic.

There are a few points to note about "determinism":

1) The standard says that an implementation *may* get rid of some copy
constructors; it does not demand it. Thus the indeterminism lies in the fact
that the programmer does not know whether this has happened to their code,
unless the compiler is kind enough to say so (compilers are the strong
silent type, and don't usually tell you anything about what they're thinking)
2) Removing copy constructors is intended as an optimisation. But
optimisations should never change the meaning of a program - that is, the
program should produce the same results with and without the optimisation.
Clearly, removing "irrelevant" copy constructors is a different kind of
thing altogether.

I think this part of the standard is a little dangerous. I accept that
removing copy constructors is a useful optimisation however (though I
haven't seen any benchmarks to show how big a speedup you get - perhaps
someone could post some to convince us all that it's worthwhile). There are
a few things that might improve the situation:

1) if an implemention removes a copy constructor, the standard should demand
that it issues a warning message (if the user desires...). Though I guess
most people will turn this warning off after a couple of hours, so maybe
that's not so smart.
2) the standard should include some specified way of switching off the
removal of copy constructors. If it's in the standard then it's
transportable, so no problems there. Perhaps some ugly #pragma or something?


Cheers,

William McIlhagga
william.mc@pi.se


[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  summarized in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
]

In article HAA19423@mail.pi.se, william.mc@pi.se (William McIlhagga) writes:

>1) The standard says that an implementation *may* get rid of some copy
>constructors; it does not demand it. Thus the indeterminism lies in the fact
>that the programmer does not know whether this has happened to their code,
>unless the compiler is kind enough to say so (compilers are the strong
>silent type, and don't usually tell you anything about what they're thinking)

>2) Removing copy constructors is intended as an optimisation. But
>optimisations should never change the meaning of a program - that is, the
>program should produce the same results with and without the optimisation.
>Clearly, removing "irrelevant" copy constructors is a different kind of
>thing altogether.

>I think this part of the standard is a little dangerous. I accept that
>removing copy constructors is a useful optimisation however (though I
>haven't seen any benchmarks to show how big a speedup you get - perhaps
>someone could post some to convince us all that it's worthwhile). There are
>a few things that might improve the situation:

>1) if an implemention removes a copy constructor, the standard should demand
>that it issues a warning message (if the user desires...). Though I guess
>most people will turn this warning off after a couple of hours, so maybe
>that's not so smart.

>2) the standard should include some specified way of switching off the
>removal of copy constructors. If it's in the standard then it's
>transportable, so no problems there. Perhaps some ugly #pragma or something?

The problem is not just that a copy constructor might be elided in code like
 T t = T(x); // T is some type
Whether the temp gets elided might depend on the optimization level that
was set or whether debugging is turned on.

The compiler is also allowed to create extra temps where convenient.

In addition, unless you are EXTREMELY knowledgeable about very fine
semantic details of C++, you will be unable to determine reliably where
temps must be created according to the language semantics. Even if you
have this deep knowledge, it takes a very careful analysis of even a
simple expression like
 x = a + b + c;
to determine where (if anywhere) temps must be created. It depends on
the parameter types of the functions called, which further depends on
the way overloaded function calls are resolved.

I really don't think you want to get messages about every temp that
was created and every optional temp that was omitted. I also don't think
you want to try to tell the compiler where it should and where it should
not omit unneeded temps.

Instead, the basic design rule is that program correctness should not
depend on exactly how many temps get created. Even with the compiler
options you are asking for, a program with such a dependence would be
unmaintainable.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

william.mc@pi.se (William McIlhagga) writes:
>1) The standard says that an implementation *may* get rid of some copy
>constructors; it does not demand it. Thus the indeterminism lies in the fact
>that the programmer does not know whether this has happened to their code,
>unless the compiler is kind enough to say so (compilers are the strong
>silent type, and don't usually tell you anything about what they're thinking)

This indeterminism is completely invisible for copy constructors that
perform a copy operation and do nothing else.  It only shows up if the
code writer includes side effects (printing of messages, etc).

>2) Removing copy constructors is intended as an optimisation. But
>optimisations should never change the meaning of a program - that is, the
>program should produce the same results with and without the optimisation.

Which is why programmers must write copy constructors in such a way as to
make this true (the program should produce the same results).  If the
removal of a copy constructor changes the meaning of your program, you've
written a broken copy constructor.  It simply is not a problem in
practice.




--
-- Joe Buck  <jbuck@synopsys.com> (not speaking for Synopsys, Inc)

Work for something because it is good,
not just because it stands a chance to succeed.    -- Vaclav Havel
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  Moderation policy:
  http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]