🚀 go-pugleaf

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