In article 27354@mulga.cs.mu.OZ.AU, fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>Michael Cook <mcook@cognex.com> writes:
>
>>>>>>> "SC" == Steve Clamage <clamage@Eng.sun.com> writes:
>>
>> SC> Silly example: Write a message to the terminal from the copy
>> SC> constructor. If the copy is optimized away, you won't see the message.
>>
>>If the constructor writes a message to the terminal, then the contructor has
>>side effects.  Such a constructor could not be optimized away and still
>>conform to the (drafts) standard, right?
>
>No, that's not right.  The draft standard explicitly gives implementations
>permission to optimize away copy constructors in this situation
>*even if they have side effects*.

Michael may have been thinking of the rule about unused variables. An
apparently unused variable must not be optimized away if its constructor
or destructor have side effects. (If they have no side effects, your
program couldn't tell whether the unused variable was created or destroyed
anyway.)

It is sometimes also necessary to point out the difference between copy
construction and copy assignment.
 // T is a type, and x is not type T
 T t1 = x; // may omit a temp T and avoid copying it
 T t2;
 t2 = x; // must create a temp T and assign it to t2
---
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 summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

clamage@Eng.Sun.COM (Steve Clamage) writes:
 ...
>It is sometimes also necessary to point out the difference between copy
>construction and copy assignment.
> // T is a type, and x is not type T
> T t1 = x; // may omit a temp T and avoid copying it
> T t2;
> t2 = x; // must create a temp T and assign it to t2

This only applies if class T does not define an "operator=(X const&)"
(or, similar ones taking an X or an X&), where x's type is X, right?


Alex
--
DISCLAIMER: these are TOTALLY personal opinions and viewpoints, NOT connected
in any way with my employer, nor any other organization or individual!
Email: martelli@cadlab.it                            Phone: +39 (51) 597313
CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia   Fax: +39 (51) 597120
---
[ 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://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article 814802135@cadlab, martelli@cadlab.cadlab.it (Alex Martelli) writes:
>clamage@Eng.Sun.COM (Steve Clamage) writes:
> ...
>>It is sometimes also necessary to point out the difference between copy
>>construction and copy assignment.
>> // T is a type, and x is not type T
>> T t1 = x; // may omit a temp T and avoid copying it
>> T t2;
>> t2 = x; // must create a temp T and assign it to t2
>
>This only applies if class T does not define an "operator=(X const&)"
>(or, similar ones taking an X or an X&), where x's type is X, right?

Right. I was trying to make the point that copy construction can
sometimes be omitted, but copy assignment cannot be optimized away.
(Modulo the "as-if" rule. If you can't detect a difference, there
isn't a difference.)

Once again, I only point this out to emphasize that you should design
classes so that the correctness of the program does not depend on whether
extra temporaries are created and copied. The language definition allows
implementors considerable leeway in creating or avoiding temps.
---
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 summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article 814802135@cadlab, martelli@cadlab.cadlab.it (Alex Martelli) writes:
>clamage@Eng.Sun.COM (Steve Clamage) writes:
> ...
>>It is sometimes also necessary to point out the difference between copy
>>construction and copy assignment.
>> // T is a type, and x is not type T
>> T t1 = x; // may omit a temp T and avoid copying it
>> T t2;
>> t2 = x; // must create a temp T and assign it to t2
>
>This only applies if class T does not define an "operator=(X const&)"
>(or, similar ones taking an X or an X&), where x's type is X, right?

Right. I was trying to make the point that copy construction can
sometimes be omitted, but copy assignment cannot be optimized away.
(Modulo the "as-if" rule. If you can't detect a difference, there
isn't a difference.)

Once again, I only point this out to emphasize that you should design
classes so that the correctness of the program does not depend on whether
extra temporaries are created and copied. The language definition allows
implementors considerable leeway in creating or avoiding temps.
---
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 summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article 813960961@molly.cs.monash.edu.au, damian@molly.cs.monash.edu.au (Damian Conway) writes:
>:-)
>
>BTW: What was the rationale for making something as fundamental as copy
>     initialization non-portable (in the sense that it has no guaranteed
>     semantics)?

The semantics of copy-initialization are well-defined, AFAIK. The exact
circumstances under which a temporary is generated and copy construction
therefore is needed is left unspecified in some cases. In cases where a
temporary might be needed but can be optionally optimized away, the
copy constructor must be accessible even if unused. This ensures code
will compile or fail consistently independent of compiler optimizations.

Here is the classic example:

 T f() { return T(); }
 T t = f();

How many copies of the returned T object are made? Would you suggest
requiring that a T local to f be created, copied to a temporary that
is the returned value from f, then copied to 't'?  Logically, that is
what happens. Under current rules, any of the copies may be omitted;
the compiler can construct a T object directly in 't' with no copies.

Some compilers do make that optimization. But the function calling
conventions on some systems require generating at least one of the
copies. So either the standard would mandate less efficient code
(the compiler must create and destroy extra copies of T), or the
standard would require omitting copies that cannot be omitted
on some systems.** You could then not get a conforming C++ compiler
on such systems. Or a conforming C++ compiler would violate the
system ABI and could not be used in conjunction with other compilers.

Instead, the standard allows omitting extra copies in some circumstances.

Because of this tradeoff, you should write copy constructors in such a
way that program correctness doesn't depend on whether a temporary
copy is optimized away. That is all we are really talking about.
---
Steve Clamage, stephen.clamage@eng.sun.com

**That point might need some explanation. When a function returns a
structured type by value, where does that value go? You can't put a
big object in a register. Some systems put it on the stack, and that
means copying that temporary object to its destination. Other systems
use the convention that the function has an extra hidden parameter which
is a pointer to the location where the return value will go. In our
example, the compiler would pass in the address of 't' as the location
for the returned T object from 'f'. The code for 'f' just creates the
T at the designated address, which might be a temporary, but in this case
is the ultimate destination. No copies are needed.


---
[ 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://dogbert.lbl.gov/~matt/std-c++/policy.html. ]