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

What I understand from reading about copy-initialization is that it needs accessible & non-explicit copy-constructor, or else the program wouldn’t compile. I verified it by writing the following code:

struct A
{
   int i;
       A(int i) : i(i) { std::cout << " A(int i)" << std::endl; }
   private:
       A(const A &a)  {  std::cout << " A(const A &)" << std::endl; }
};

int main() {
        A a = 10; //error - copy-ctor is private!
}

GCC gives an error (ideone) saying:

prog.cpp:8: error: ‘A::A(const A&)’ is private

So far everything is fine, reaffirming what Herb Sutter says,

Copy initialization means the object is initialized using the copy constructor, after first calling a user-defined conversion if necessary, and is equivalent to the form “T t = u;”:

---

After that I made the copy-ctor accessible by commenting the private keyword. Now, naturally I would expect the following to get printed:

A(const A&)

But to my surprise, it prints this instead (ideone):

A(int i)

Why?

Alright, I understand that first a temporary object of type A is created out of 10 which is int type, by using A(int i), applying the conversion rule as its needed here (§8.5/14), and then it was supposed to call copy-ctor to initialize a. But it didn’t. Why?

If an implementation is permitted to eliminate the need to call copy-constructor (§8.5/14), then why is it not accepting the code when the copy-constructor is declared private? After all, its not calling it. Its like a spoiled kid who first irritatingly asks for a specific toy, and when you give him one, the specific one, he throws it away, behind your back. 😐

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?

Answer 1

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