Strange behavior of copy-initialization, doesn't call the copy-constructor!

Question

I was reading the difference between direct-initialization and copy-initialization (§8.5/12):

T x(a);  //direct-initialization
T y = a; //copy-initialization         


        

Answer 1

C++ explicitly allows several optimizations involving the copy constructor that actually change the semantics of the program. (This is in contrast with most optimizations, which do not affect the semantics of the program). In particular, there are several cases where the compiler is allowed to re-use an existing object, rather than copying one, if it knows that the existing object will become unreachable. This (copy construction) is one such case; another similar case is the "return value optimization" (RVO), where if you declare the variable that holds the return value of a function, then C++ can choose to allocate that on the frame of the caller, so that it doesn't need to copy it back to the caller when the function completes.

In general, in C++, you are playing with fire if you define a copy constructor that has side effects or does anything other than just copying.

Answer 2

Here you can find this (with your comment ;)):

[the standard] also says that the temporary copy can be elided, but the semantic constraints (eg. accessibility) of the copy constructor still have to be checked.

Answer 3

Are you asking why the compiler does the access check? 12.8/14 in C++03:

A program is ill-formed if the copy constructor or the copy assignment operator for an object is implicitly used and the special member function is not accessible

When the implementation "omits the copy construction" (permitted by 12.8/15), I don't believe this means that the copy ctor is no longer "implicitly used", it just isn't executed.

Or are you asking why the standard says that? If copy elision were an exception to this rule about the access check, your program would be well-formed in implementations that successfully perform the elision, but ill-formed in implementations that don't.

I'm pretty sure the authors would consider this a Bad Thing. Certainly it's easier to write portable code this way -- the compiler tells you if you write code that attempts to copy a non-copyable object, even if the copy happens to be elided in your implementation. I suspect that it could also inconvenience implementers to figure out whether the optimization will be successful before checking access (or to defer the access check until after the optimization is attempted), although I have no idea whether that warranted consideration.

Could this behavior be dangerous? I mean, I might do some other useful thing in the copy-ctor, but if it doesn't call it, then does it not alter the behavior of the program?

Of course it could be dangerous - side-effects in copy constructors occur if and only if the object is actually copied, and you should design them accordingly: the standard says copies can be elided, so don't put code in a copy constructor unless you're happy for it to be elided under the conditions defined in 12.8/15:

MyObject(const MyObject &other) {
    std::cout << "copy " << (void*)(&other) << " to " << (void*)this << "\n"; // OK
    std::cout << "object returned from function\n"; // dangerous: if the copy is
      // elided then an object will be returned but you won't see the message.
}

Answer 4

In any compiler, syntax [and semantic] analysis process are done prior to the code optimization process.

The code must be syntactically valid otherwise it won't even compile. Its only in the later phase (i.e code optimization) that the compiler decides to elide the temporary that it creates.

So you need an accessible copy c-tor.

Answer 5

RVO and NRVO, buddy. Perfectly good case of copy ellision.

Answer 6

This is an optimization by the compiler.

In evaluating: A a = 10; instead of:

1. first constructing a temporary object through A(int);

2. constructing a through the copy constructor and passing in the temporary;

the compiler will simply construct a using A(int).