2

This code

#include <iostream>

struct A
{
    A(int i) {std::cout << "int received\n";}
    A(A& a) {std::cout << "ref received\n";}
};

int main()
{
    int j = 5;
    A a = j;
}

unexpectedly throws the following compiler error:

error: invalid initialization of non-const reference of type 'A&' from an rvalue of type 'A'
note:   initializing argument 1 of 'A::A(A&)'
note:   after user-defined conversion: A::A(int)

When I remove the second constructor overload A(A& a), everything works as expected. I suppose that the compiler mistakenly calls the second constructor instead of the first one.

Why does this happen?

How can I have a class with both a reference constructor and an rvalue constructor work in harmony?

I use GNU GCC.

Note: I also noticed something weird: Apparently, if I replace the line A a = j; with A a(j);, everything works as expected. This however is not satisfactory because it still doesn't work if I'm trying to initialize the object from a function argument (ex: calling void f(A a) with f(j)).

songyuanyao
  • 169,198
  • 16
  • 310
  • 405
GT 77
  • 448
  • 5
  • 12
  • The implicit conversion appears to be the key here. And I bet following the rules of 0/3/5 as appropriate would solve this! – underscore_d Jun 02 '20 at 10:32
  • 1
    Time to learn about [the value categories of C++](https://en.cppreference.com/w/cpp/language/value_category). Rvalues (like the temporary object created through the conversion of `j`) can't be bound to lvalue references as the `A(A&)` constructor expects. You need to use references to *constant* objects for it to work, as in `A(A const&)`. – Some programmer dude Jun 02 '20 at 10:33
  • 1
    Interesting example. Goes to show how C++ evolves. This went from invalid C++14 to valid C++17. – StoryTeller - Unslander Monica Jun 02 '20 at 10:42
  • Terminology: `A(A&)` is a **copy constructor**. It's not the most common form; `A(const A&)` is what you'll almost always see. But it's a copy constructor nonetheless. – Pete Becker Jun 02 '20 at 12:14

1 Answers1

3

A a = j; performs copy initialization.

Until C++17,

If T is a class type, and the cv-unqualified version of the type of other is not T or derived from T, or if T is non-class type, but the type of other is a class type, user-defined conversion sequences that can convert from the type of other to T (or to a type derived from T if T is a class type and a conversion function is available) are examined and the best one is selected through overload resolution. The result of the conversion, which is a prvalue temporary (until C++17) prvalue expression (since C++17) if a converting constructor was used, is then used to direct-initialize the object. The last step is usually optimized out and the result of the conversion is constructed directly in the memory allocated for the target object, but the appropriate constructor (move or copy) is required to be accessible even though it's not used. (until C++17)

Class A has a copy construtor taking lvalue-reference to non-const, which can't bind to the temporary converted from int. Even the construction from the temporary A might be optimized the copy constructor has to be available.

Making the copy constructor taking lvalue-reference to const (or adding move constructor) would solve the issue.

Since C++17 because of mandatory copy elision, the code would work fine.

The objects are constructed directly into the storage where they would otherwise be copied/moved to. The copy/move constructors need not be present or accessible:

LIVE

On the other hand, A a(j); performs direct initialization, a is initialized from j directly, copy constructor doesn't involve in.

songyuanyao
  • 169,198
  • 16
  • 310
  • 405
  • If you'd like to refer to the standard instead of/in addition to (as this was a quite interesting example from standard evolution standpoint) cppreference, the relevant section is [\[class.copy\]/32](https://timsong-cpp.github.io/cppwp/n4140/class.copy#32) in N4140 (_C++14 + editorial fixes_) and changed to C++17 (partly) as per [P0135R1](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0135r1.html). I can't find the paper which entirely removes \[class.copy\]/32, though. – dfrib Jun 02 '20 at 10:59
  • @dfri Thanks. The selection [class.copy]/32 seems focusing on the two-stage overload resolution for return statement, and I think there should be more appropriate one for this case but I can't find in the standard for now.. – songyuanyao Jun 02 '20 at 11:07
  • Yes you are right; I can't seem to find the relevant section myself (it may be spread out in different sections of the standard and neatly summarized at cppreference). – dfrib Jun 02 '20 at 11:16