Suppose I have this function:
void my_test()
{
A a1 = A_factory_func();
A a2(A_factory_func());
double b1 = 0.5;
double b2(0.5);
A c1;
In C++17, the meaning of A_factory_func()
changed from creating a temporary object (C++<=14) to just specifying the initialization of whatever object this expression is initialized to (loosely speaking) in C++17. These objects (called "result objects") are the variables created by a declaration (like a1
), artificial objects created when the initialization ends up being discarded, or if an object is needed for reference binding (like, in A_factory_func();
. In the last case, an object is artificially created, called "temporary materialization", because A_factory_func()
doesn't have a variable or reference that otherwise would require an object to exist).
As examples in our case, in the case of a1
and a2
special rules say that in such declarations, the result object of a prvalue initializer of the same type as a1
is variable a1
, and therefore A_factory_func()
directly initializes the object a1
. Any intermediary functional-style cast would not have any effect, because A_factory_func(another-prvalue)
just "passes through" the result object of the outer prvalue to be also the result object of the inner prvalue.
A a1 = A_factory_func();
A a2(A_factory_func());
Depends on what type A_factory_func()
returns. I assume it returns an A
- then it's doing the same - except that when the copy constructor is explicit, then the first one will fail. Read 8.6/14
double b1 = 0.5;
double b2(0.5);
This is doing the same because it's a built-in type (this means not a class type here). Read 8.6/14.
A c1;
A c2 = A();
A c3(A());
This is not doing the same. The first default-initializes if A
is a non-POD, and doesn't do any initialization for a POD (Read 8.6/9). The second copy initializes: Value-initializes a temporary and then copies that value into c2
(Read 5.2.3/2 and 8.6/14). This of course will require a non-explicit copy constructor (Read 8.6/14 and 12.3.1/3 and 13.3.1.3/1 ). The third creates a function declaration for a function c3
that returns an A
and that takes a function pointer to a function returning a A
(Read 8.2).
Delving into Initializations Direct and Copy initialization
While they look identical and are supposed to do the same, these two forms are remarkably different in certain cases. The two forms of initialization are direct and copy initialization:
T t(x);
T t = x;
There is behavior we can attribute to each of them:
T
(including explicit
ones), and the argument is x
. Overload resolution will find the best matching constructor, and when needed will do any implicit conversion required. x
to an object of type T
. (It then may copy over that object into the to-initialized object, so a copy constructor is needed too - but this is not important below)As you see, copy initialization is in some way a part of direct initialization with regard to possible implicit conversions: While direct initialization has all constructors available to call, and in addition can do any implicit conversion it needs to match up argument types, copy initialization can just set up one implicit conversion sequence.
I tried hard and got the following code to output different text for each of those forms, without using the "obvious" through explicit
constructors.
#include
struct B;
struct A {
operator B();
};
struct B {
B() { }
B(A const&) { std::cout << " "; }
};
A::operator B() { std::cout << " "; return B(); }
int main() {
A a;
B b1(a); // 1)
B b2 = a; // 2)
}
// output:
How does it work, and why does it output that result?
Direct initialization
It first doesn't know anything about conversion. It will just try to call a constructor. In this case, the following constructor is available and is an exact match:
B(A const&)
There is no conversion, much less a user defined conversion, needed to call that constructor (note that no const qualification conversion happens here either). And so direct initialization will call it.
Copy initialization
As said above, copy initialization will construct a conversion sequence when a
has not type B
or derived from it (which is clearly the case here). So it will look for ways to do the conversion, and will find the following candidates
B(A const&)
operator B(A&);
Notice how I rewrote the conversion function: The parameter type reflects the type of the this
pointer, which in a non-const member function is to non-const. Now, we call these candidates with x
as argument. The winner is the conversion function: Because if we have two candidate functions both accepting a reference to the same type, then the less const version wins (this is, by the way, also the mechanism that prefers non-const member function calls for non-const objects).
Note that if we change the conversion function to be a const member function, then the conversion is ambiguous (because both have a parameter type of A const&
then): The Comeau compiler rejects it properly, but GCC accepts it in non-pedantic mode. Switching to -pedantic
makes it output the proper ambiguity warning too, though.
I hope this helps somewhat to make it clearer how these two forms differ!