🚀 go-pugleaf

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