What is copy/move constructor choosing rule in C++? When does move-to-copy fallback happen?

Question

The first example:

#include 
#include 
using namespace std;

struct A {
    unique_ptr ref;
    A(const A&) = de         


        

Answer 1

There is no "fallback". It is called overload resolution. If there are more than one possible candidate in overload resolution then the best match is chosen, according to a complicated set of rules which you can find by reading the C++ standard or a draft of it.

Here is an example without constructors.

class X { };

void func(X &&) { cout << "move\n"; }            // 1
void func(X const &)  { cout << "copy\n"; }      // 2

int main()
{
    func( X{} );
}

• As-is: prints "move"
• Comment out "1": prints "copy"
• Comment out "2": prints "move"
• Comment out "1" and "2": fails to compile

In overload resolution, binding rvalue to rvalue has higher preference than lvalue to rvalue.

---

Here is a very similar example:

void func(int) { cout << "int\n"; }      // 1
void func(long) { cout << "long\n"; }    // 2

int main()
{
     func(1);
}

• As-is: prints "int"
• Comment out "1": prints "long"
• Comment out "2": prints "int"
• Comment out "1" and "2": fails to compile

In overload resolution, an exact match is preferred to a conversion.

---

In your three examples on this thread we have:

1: Two candidate functions; rvalue prefers rvalue (as in my first example)

A(const A&);
A(A&&);           // chosen

2: Two candidate functions; rvalue prefers rvalue (as in my first example)

A(const A&); 
A(A&&);           // chosen

3: One candidate function; no contest

A(const A&);      // implicitly declared, chosen

As explained earlier, there is no implicit declaration of A(A&&) in case 3 because you have a destructor.

For overload resolution it does not matter whether the function body exists or not, it is whether the function is declared (either explicitly or implicitly).

Answer 2

The function that it's going to use is chosen before it checks if it is deleted or not. In the case that the copy constructor was available and the move constructor was deleted, the move constructor was still the best choice out of the two. Then it sees that it's deleted and gives you an error.

If you had the same example but actually removed the move constructor, rather than making it deleted, you'll see that it compiles fine and does fall back to use the copy constructor:

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

struct A {
    unique_ptr<int> ref;
    A(const A&a) 
        : ref( a.ref.get() ? new int(*a.ref) : nullptr )
    {  }
    A(const int i) : ref(new int(i)) { }
    ~A() = default;
};

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

This class does not have a move constructor declared for it at all (not even implicitly), therefore it cannot be chosen.