Why does the compiler require a copying constructor, need and have moving one and doesn't uses any of them?

Question

I've already tried to ask this question but I wasn't clear enough. So here is one more try. And I am very sorry for my English ;)

Let's see the code:

#include <iostream>
#include <memory>
using namespace std;

struct A {
    unique_ptr<int> ref;

    void printRef() {
        if (ref.get())
            cout<<"i="<<*ref<<endl;
        else
            cout<<"i=NULL"<<endl;
    }

    A(const int i) : ref(new int(i)) { 
        cout<<"Constructor with ";
        printRef();
    }
    ~A() {
        cout<<"Destructor with";
        printRef();
    }
};

int main()
{
    A a[2] = { 0, 1 };
   return 0;
}

It can not be compiled because unique_ptr has deleted copying constructor.
Orly?!
This class DOES HAVE an implied moving constructor because unique_ptr has one.

Let's do a test:

#include <iostream>
#include <memory>
using namespace std;

struct A {
    unique_ptr<int> ref;

    void printRef() {
        if (ref.get())
            cout<<"i="<<*ref<<endl;
        else
            cout<<"i=NULL"<<endl;
    }

    A(const int i) : ref(new int(i)) { 
        cout<<"Constructor with ";
        printRef();
    }
    // Let's add a moving constructor.
    A(A&& a) : ref(std::move(a.ref)) { 
        cout<<"Moving constructor with";
        printRef();
    }
    ~A() {
        cout<<"Destructor with";
        printRef();
    }
};

int main()
{
    A a[2] = { 0, 1 };
   return 0;
}

I've added a moving constructor and now the code can be compiled and executed.
Even if the moving constructor is not used.
The output:

Constructor with i=0
Constructor with i=1
Destructor withi=1
Destructor withi=0

Okay...
Let's do one more test and remove the copying constructor (but leave the moving one).
I don't post the code, there only one line has been added:

A(const A& a) = delete;

You should trust me - it works. So the compiler doesn't require a copying constructor. But it did! (a facepalm should be here)
So what's going on? I see it completely illogical! Or is there some sort of twisted logic I don't see?

Once more:
unique_ptr has a moving constructor and has a deleted copying constructor. Compiler requires copying constructor to be present. But in fact the compiler requires a moving constructor (even if it is not used) and doesn't require a copying (because it could be deleted). And as I see the moving constructor is (should be?) present impliedly.
What's wrong with that?

P.S. One more thing - if I delete the moving constructor the program could not be compiled. So the moving constructor is required, but not the copying one.
Why does it require copy-constructor if it's prohibited to use it there?

P.P.S. Big thanks to juanchopanza's answer! This can be solved by:

A(A&& a) = default;

And also big thanks to Matt McNabb.
As I see it now, the moving constructor is absent because unique_ptr doesn't have a copying one the class has a destructor (and the general rule is that default/copying/moving constructors and destructor could be generated by default only all together). Then the compiler doesn't stop at moving one (why?!) and falls back to copying one. At this point the compiler can't generate it and stops with an error (about the copy constructor) when nothing else can be done.

By the way it you add:

A(A&& a) = delete;
A(const A& a) = default;

It could NOT be compiled with error about 'A::A(A&& a)' deletion, There will be no fall back to copying constructor.

P.P.P.S The last question - why does it stop with error at the COPY constructor but not the MOVE constructor?!
GCC++ 4.7/4.8 says: "error: use of deleted function ‘A::A(const A&)’"
So it stops at copy constructor.
Why?! There should be 'A::A(A&&)'

Ok. Now it seems like a question about move/copy constrcutor choosing rule.
I've created the new more specific question here

Answer 1

This is called copy elision.

The rule in this situation is that a copy/move operation is specified, but the compiler is allowed to optionally elide it as an optimization, even if the copy/move constructor had side-effects.

When copy elision happens, typically the object is created directly in the memory space of the destination; instead of creating a new object and then copy/moving it over to the destination and deleting the first object.

The copy/move constructor still has to actually be present, otherwise we would end up with stupid situations where the code appears to compile, but then fails to compile later when the compiler decides not to do copy-elision. Or the code would work on some compilers and break on other compilers, or if you used different compiler switches.

---

In your first example you do not declare a copy nor a move constructor. This means that it gets an implicitly-defined copy-constructor.

However, there is a rule that if a class has a user-defined destructor then it does not get an implicitly-defined move constructor. Don't ask me why this rule exists, but it does (see [class.copy]#9 for reference).

Now, the exact wording of the standard is important here. In [class.copy]#13 it says:

A copy/move constructor that is defaulted and not defined as deleted is implicitly defined if it is odr-used (3.2)

[Note: The copy/move constructor is implicitly defined even if the implementation elided its odr-use (3.2, 12.2). —end note

The definition of odr-used is quite complicated, but the gist of it is that if you never attempt to copy the object then it will not try to generate the implicitly-defined copy constructor (and likewise for moving and move).

As T.C. explains on your previous thread though, the act of doing A a[2] = {0, 1}; does specify a copy/move, i.e. the value a[0] must be initialized either by copy or by move, from a temporary A(0). This temporary is able to undergo copy elision, but as I explain earlier, the right constructors must still exist so that the code would work if the compiler decides not to use copy elision in this case.

Since your class does not have a move constructor here, it cannot be moved. But the attempt to bind the temporary to a constructor of A still succeeds because there is a copy-constructor defined (albeit implicitly-defined). At that point, odr-use happens and it attempts to generate the copy-constructor and fails due to the unique_ptr.

---

In your second example, you provide a move-constructor but no copy-constructor. There is still an implicitly-declared copy-constructor which is not generated until it is odr-used, as before.

But the rules of overload resolution say that if a copy and a move are both possible, then the move constructor is used. So it does not odr-use the copy-constructor in this case and everything is fine.

In the third example, again the move-constructor wins overload resolution so it does not matter what how the copy-constructor is defined.

Answer 2

I think you are asking why this

A a[2] = { 0, 1 };

fails to compile, while you would expect it to compile because A may have a move constructor. But it doesn't.

The reason is that A has a member that is not copyable, so its own copy constructor is deleted, and this counts as a user declared copy constructor has a user-declared destructor.

This in turn means A has no implicitly declared move constructor. You have to enable move construction, which you can do by defaulting the constructor:

A(A&&) = default;

To check whether a class is move constructible, you can use is_move_constructible, from the type_traits header:

std::cout << std::boolalpha;
std::cout << std::is_move_constructible<A>::value << std::endl;

This outputs false in your case.

Answer 3

The twisted logic is that you are supposed to write programs at a higher abstraction level. If an object has a copy constructor it can be copied, otherwise it cannot. If you tell the compiler this object shall not be copied it will obey you and not cheat. Once you tell it that it can be copied the compiler will try to make the copy as fast as possible, usually by avoiding the copy constructor.

As for the move constructor: It is an optimization. It tends to be faster to move an object from one place to another than to make an exact copy and destroy the old one. This is what move constructors are for. If there is no move constructor the move can still be done with the old fashioned copy and destroy method.