Copy Constructor didn't call, why?

Question

Possible Duplicate:
Why copy constructor is not called in this case?

I have following code:

#include <iostream>
#include <new>

using namespace std;

class test {  
    int *p;  
public:
    test operator=(test a);
    test()  {
        p = new int [2];
        cout <<"Default Constructor was done here." << "\n";
    }

    test(const test &a) {
        p = new int [2];
        this->p[0] = a.p[0];
        this->p[1] = a.p[1];
        cout << "Copy Constructor was done here." << "\n";
    }

    ~test() {
        delete p;
        cout << "Destructor was done here." << "\n";
    }
    int set (int a, int b) {
        p[0] = a;
        p[1] = b;
        return 1;
    }

    int show () {
        cout << p[0] << " " << p[1] << "\n";
        return 2;
    }
};    

test test::operator=(test a) {
    p[0] = a.p[0]; 
    p[1] = a.p[1]; 
    cout << "Operator = was done here" << "\n";
    return *this;
}

test f(test x) {
    x.set(100, 100);
    return x;
}

int main () {
    test first;
    test second;
    first.set(12, 12);

    //f(first);
    //second = first;
    second = f(first);


    first.show();
    second.show();

    getchar ();
    return 0;
}

Copy Constructor was called only three times? Why? If I understand, we made four copies (we send object to func, func returns value, we send object to operator=, operator= returns value).

Answer 1

This is likely an effect of copy elision. The compiler is free to avoid copying objects wherever it doesn't make an impact on the program. Side effects of copy-constructor/destructor are not considered as an impact on the program in this caser. In general it will avoid copying a temporary for use as a function parameter, since the temporary would be destroyed afterwards anyways.

This can be found in §12.8.32 in the standard:

When certain criteria are met, an implementation is allowed to omit the copy/move construction of a class object, even if the copy/move constructor and/or destructor for the object have side effects. In such cases, the implementation treats the source and target of the omitted copy/move operation as simply two different ways of referring to the same object, and the destruction of that object occurs at the later of the times when the two objects would have been destroyed without the optimization. This elision of copy/move operations, called copyelision, is permitted in the following circumstances (which maybe combined to eliminate multiple copies):

• in a return statement in a function with a class return type, when the expression is the name of a non-volatile automatic object with
  the same cv-unqualified type as the function return type, the
  copy/move operation can be omitted by constructing the automatic
  object directly into the function’s return value
• in a throw-expression, when the operand is the name of a non-volatile automatic object whose scope does not extend beyond the end of the innermost enclosing try-block (if there is one), the copy/move operation from the operand to the exception object (15.1) can be omitted by constructing the automatic object directly into the exception object
• when a temporary class object that has not been bound to a reference (12.2) would becopied/moved to a class object witht he same cv-unqualified type, the copy/move operation can be omitted by constructing the temporary object directly into the target of the
  omitted copy/move
• when the exception-declaration of an exception handler (Clause 15) declares an object of the same type (except for cv-qualification) as
  the exception object (15.1), the copy/move operation can be omitted
  bytreatingthe exception-declaration as an alias for the exception
  object if the meaning of the program will be unchanged except for the execution of constructors and destructors for the object declared by
  the exception-declaration.

In this case it will likely simply use the object returned by f as input for the operator=, since it is a temporary and would therefore be destroyed right afterwards anyways.