In order to compile a function call, the compiler must first perform name lookup, which, for functions, may involve argument-dependent lookup, and for function templates may be followed by template argument deduction.
If the name refers to more than one entity, it is said to be overloaded, and the compiler must determine which overload to call. In simple terms, the overload whose parameters match the arguments most closely is the one that is called.
In detail, overload resolution proceeds through the following steps:
void f(long); void f(float); f(0L); // calls f(long) f(0); // error: ambiguous overload
Besides function calls, overloaded function names may appear in several additional contexts, where different rules apply: see Address of an overloaded function.
If a function cannot be selected by overload resolution, it cannot be used (e.g. it is a templated entity with a failed constraint).
[edit] Candidate functionsBefore overload resolution begins, the functions selected by name lookup and template argument deduction are combined to form the set of candidate functions. The exact details depend on the context in which overload resolution will take place.
[edit] Call to a named functionIf E in a function call expression E(args) names a set of overloaded functions and/or function templates (but not callable objects), the following rules are followed:
T), then B is looked up as a member function of T. The function declarations found by that lookup are the candidate functions. The argument list for the purpose of overload resolution has the implied object argument of type cv T.T, in which case, if this is in scope and is a pointer to T or to a derived class of T, *this is used as the implied object argument. Otherwise (if this is not in scope or does not point to T), a fake object of type T is used as the implied object argument, and if overload resolution subsequently selects a non-static member function, the program is ill-formed.If E in a function call expression E(args) has class type cv T, then
T are obtained by ordinary lookup of the name operator() in the context of the expression (E).operator(), and every declaration found is added to the set of candidate functions.explicit user-defined conversion function in T or in a base of T (unless hidden), whose cv-qualifiers are the same or greater than T's cv-qualifiers, and where the conversion function converts to:In any case, the argument list for the purpose of overload resolution is the argument list of the function call expression preceded by the implied object argument E (when matching against the surrogate function, the user-defined conversion will automatically convert the implied object argument to the first argument of the surrogate function).
int f1(int);
int f2(float);
struct A
{
using fp1 = int(*)(int);
operator fp1() { return f1; } // conversion function to pointer to function
using fp2 = int(*)(float);
operator fp2() { return f2; } // conversion function to pointer to function
} a;
int i = a(1); // calls f1 via pointer returned from conversion function[edit] Call to an overloaded operator
If at least one of the arguments to an operator in an expression has a class type or an enumeration type, both builtin operators and user-defined operator overloads participate in overload resolution, with the set of candidate functions selected as follows:
For a unary operator @ whose argument has type T1 (after removing cv-qualifications), or binary operator @ whose left operand has type T1 and right operand of type T2 (after removing cv-qualifications), the following sets of candidate functions are prepared:
: if
T1
is a complete class or a class currently being defined, the set of member candidates is the result of
qualified name lookupof
T1::operator@
. In all other cases, the set of member candidates is empty.
2) non-member candidates: For the operators where
operator overloadingpermits non-member forms, all declarations found by
unqualified name lookupof
operator@
in the context of the expression (which may involve
ADL), except that member function declarations are ignored and do not prevent the lookup from continuing into the next enclosing scope. If both operands of a binary operator or the only operand of a unary operator has enumeration type, the only functions from the lookup set that become non-member candidates are the ones whose parameter has that enumeration type (or reference to that enumeration type)
3) built-in candidates: For
operator,, the unary
operator&, and
operator->, the set of built-in candidates is empty. For other operators built-in candidates are the ones listed in
built-in operator pagesas long as all operands can be implicitly converted to their parameters. If any built-in candidate has the same parameter list as a non-member candidate
or rewritten non-member candidate(since C++20)that is not a function template specialization, it is not added to the list of built-in candidates. When the built-in assignment operators are considered, the conversions from their first parameters are restricted: only the
standard conversion sequencesare considered.
4) rewritten candidates:
In all cases, rewritten candidates are not considered in the context of the rewritten expression. For all other operators, the rewritten candidate set is empty.
(since C++20)The set of candidate functions to be submitted for overload resolution is a union of the sets above. The argument list for the purpose of overload resolution consists of the operands of the operator except for operator->, where the second operand is not an argument for the function call (see member access operator).
struct A
{
operator int(); // user-defined conversion
};
A operator+(const A&, const A&); // non-member user-defined operator
void m()
{
A a, b;
a + b; // member-candidates: none
// non-member candidates: operator+(a, b)
// built-in candidates: int(a) + int(b)
// overload resolution chooses operator+(a, b)
}
If the overload resolution selects a built-in candidate, the user-defined conversion sequence from an operand of class type is not allowed to have a second standard conversion sequence: the user-defined conversion function must give the expected operand type directly:
struct Y { operator int*(); }; // Y is convertible to int*
int *a = Y() + 100.0; // error: no operator+ between pointer and double
For operator,, the unary operator&, and operator->, if there are no viable functions (see below) in the set of candidate functions, then the operator is reinterpreted as a built-in.
If a rewritten operator<=> candidate is selected by overload resolution for an operator @, x @ y is interpreted as the rewritten expression: 0 @ (y <=> x) if the selected candidate is a synthesized candidate with reversed order of parameters, or (x <=> y) @ 0 otherwise, using the selected rewritten operator<=> candidate.
If a rewritten operator== candidate is selected by overload resolution for an operator @ (which is either == or !=), its return type must be (possibly cv-qualified) bool, and x @ y is interpreted as the rewritten expression: y == x or !(y == x) if the selected candidate is a synthesized candidate with reversed order of parameters, or !(x == y) otherwise, using the selected rewritten operator== candidate.
Overload resolution in this case has a final tiebreaker preferring non-rewritten candidates to rewritten candidates, and preferring non-synthesized rewritten candidates to synthesized rewritten candidates.
This lookup with the reversed arguments order makes it possible to write just operator<=>(std::string, const char*) and operator==(std::string, const char*) to generate all comparisons between std::string and const char*, both ways. See default comparisons for more detail.
(since C++20) [edit] Initialization by constructorWhen an object of class type is direct-initialized or default-initialized (including default-initialization in the context of copy-list-initialization)(since C++11), the candidate functions are all constructors of the class being initialized. The argument list is the expression list of the initializer.
Otherwise, the candidate functions are all converting constructors of the class being initialized. The argument list is the expression of the initializer.
For default-initialization in the context of copy-list-initialization, if an explicit constructor is chosen, the initialization is ill-formed.
If copy-initialization of an object of class type requires that a user-defined conversion is called to convert the initializer expression of type cv S to the type cv T of the object being initialized, the following functions are candidate functions:
Texplicit conversion functions from S and its base classes (unless hidden) to T or class derived from T or a reference to such. If this copy-initialization is part of the direct-initialization sequence of cv T (initializing a reference to be bound to the first parameter of a constructor that takes a reference to cv T), then explicit conversion functions are also considered.Either way, the argument list for the purpose of overload resolution consists of a single argument which is the initializer expression, which will be compared against the first argument of the constructor or against the implicit object argument of the conversion function.
[edit] Non-class initialization by conversionWhen initialization of an object of non-class type cv1 T requires a user-defined conversion function to convert from an initializer expression of class type cv S, the following functions are candidates:
S and its base classes (unless hidden) that produce type T or a type convertible to T by a standard conversion sequence, or a reference to such type. cv-qualifiers on the returned type are ignored for the purpose of selecting candidate functions.S and its base classes (unless hidden) that produce type T or a type convertible to T by a qualification conversion, or a reference to such type, are also considered.Either way, the argument list for the purpose of overload resolution consists of a single argument which is the initializer expression, which will be compared against the implicit object argument of the conversion function.
[edit] Reference initialization by conversionDuring reference initialization, where the reference to cv1 T is bound to the lvalue or rvalue result of a conversion from the initializer expression from the class type cv2 S, the following functions are selected for the candidate set:
S and its base classes (unless hidden) to the typeT2T2 or rvalue reference to cv2 T2T2 is reference-compatible with cv1 T.
T2 is the same type as T or can be converted to type T with a qualification conversion.Either way, the argument list for the purpose of overload resolution consists of a single argument which is the initializer expression, which will be compared against the implicit object argument of the conversion function.
[edit] List-initializationWhen an object of non-aggregate class type T is list-initialized, two-phase overload resolution takes place.
T and the argument list for the purpose of overload resolution consists of a single initializer list argumentT and the argument list for the purpose of overload resolution consists of the individual elements of the initializer list.If the initializer list is empty and T has a default constructor, phase 1 is skipped.
In copy-list-initialization, if phase 2 selects an explicit constructor, the initialization is ill-formed (as opposed to all over copy-initializations where explicit constructors are not even considered).
[edit] Additional rules for function template candidatesIf name lookup found a function template, template argument deduction and checking of any explicit template arguments are performed to find the template argument values (if any) that can be used in this case:
If a name refers to one or more function templates and also to a set of overloaded non-template functions, those functions and the specializations generated from the templates are all candidates.
See function template overloading for further detail.
If a constructor template or conversion function template has a conditional explicit specifier which happens to be value-dependent, after deduction, if the context requires a candidate that is not explicit and the generated specialization is explicit, it is removed from the candidate set.
(since C++20) [edit] Additional rules for constructor candidatesDefaulted move constructors and move assignment operators that are defined as deleted are excluded in the set of candidate functions.
A constructor inherited from class type C that has a first parameter of type âreference to Pâ (including such a constructor instantiated from a template) is excluded from the set of candidate functions when constructing an object of type D if all following conditions are satisfied:
C is reference-related to P.P is reference-related to D.If any candidate function is a member function (static or non-static) that does not have an explicit object parameter(since C++23), but not a constructor, it is treated as if it has an extra parameter (implicit object parameter) which represents the object for which they are called and appears before the first of the actual parameters.
Similarly, the object on which a member function is being called is prepended to the argument list as the implied object argument.
For member functions of class X, the type of the implicit object parameter is affected by cv-qualifications and ref-qualifications of the member function as described in member functions.
The user-defined conversion functions are considered to be members of the implied object argument for the purpose of determining the type of the implicit object parameter.
The member functions introduced by a using-declaration into a derived class are considered to be members of the derived class for the purpose of defining the type of the implicit object parameter.
For the static member functions, the implicit object parameter is considered to match any object: its type is not examined and no conversion sequence is attempted for it.
(until C++23)For the rest of overload resolution, the implied object argument is indistinguishable from other arguments, but the following special rules apply to the implicit object parameter:
1) user-defined conversions cannot be applied to the implicit object parameter
2)rvalues can be bound to non-const implicit object parameter
(unless this is for a ref-qualified member function)(since C++11)and do not affect the ranking of the implicit conversions.
struct B { void f(int); };
struct A { operator B&(); };
A a;
a.B::f(1); // Error: user-defined conversions cannot be applied
// to the implicit object parameter
static_cast<B&>(a).f(1); // OK[edit] Viable functions
Given the set of candidate functions, constructed as described above, the next step of overload resolution is examining arguments and parameters to reduce the set to the set of viable functions
To be included in the set of viable functions, the candidate function must satisfy the following:
1) If there are M arguments, the candidate function that has exactly M parameters is viable
If the candidate function has less than
M
parameters, but has an
ellipsis parameter, it is viable.
3) If the candidate function has more than M parameters and the M+1'st parameter and all parameters that follow have default arguments, it is viable. For the rest of overload resolution, the parameter list is truncated at M.
If the function has an associated
constraint, it must be satisfied
(since C++20)5) For every argument there must be at least one implicit conversion sequence that converts it to the corresponding parameter.
6) If any parameter has reference type, reference binding is accounted for at this step: if an rvalue argument corresponds to non-const lvalue reference parameter or an lvalue argument corresponds to rvalue reference parameter, the function is not viable.
User-defined conversions (both converting constructors and user-defined conversion functions) are prohibited from taking part in implicit conversion sequence where it would make it possible to apply more than one user-defined conversion. Specifically, they are not considered if the target of the conversion is the first parameter of a constructor or the implicit object parameter of a user-defined conversion function, and that constructor/user-defined conversion is a candidate for
X, and the conversion is to X or reference to (possibly cv-qualified) X:struct A { A(int); };
struct B { B(A); };
B b{{0}}; // list-initialization of B
// candidates: B(const B&), B(B&&), B(A)
// {0} -> B&& not viable: would have to call B(A)
// {0} -> const B&: not viable: would have to bind to rvalue, would have to call B(A)
// {0} -> A viable. Calls A(int): user-defined conversion to A is not banned(since C++11) [edit] Best viable function
For each pair of viable function F1 and F2, the implicit conversion sequences from the ith argument to ith parameter are ranked to determine which one is better (except the first argument, the implicit object argument for static member functions has no effect on the ranking)
F1 is determined to be a better function than F2 if implicit conversions for all arguments of F1 are not worse than the implicit conversions for all arguments of F2, and
1) there is at least one argument of F1 whose implicit conversion is better than the corresponding implicit conversion for that argument of F2, or, if not that,
2) (only in context of non-class initialization by conversion), the standard conversion sequence from the result of F1 to the type being initialized is better than the standard conversion sequence from the result of F2, or, if not that,
3) (only in context of initialization by conversion function for direct reference binding of a reference to function type), the result of F1 is the same kind of reference (lvalue or rvalue) as the reference being initialized, and the result of F2 is not, or, if not that,
4) F1 is a non-template function while F2 is a template specialization, or, if not that,
F1
and
F2
are non-template functions and
F1
is
more partial-ordering-constrainedthan
F2
:
template<typename T = int>
struct S
{
constexpr void f(); // #1
constexpr void f(this S&) requires true; // #2
};
void test()
{
S<> s;
s.f(); // calls #2
}
, or, if not that,
(since C++20) 7)F1
is a constructor for a class
D
,
F2
is a constructor for a base class
B
of
D
, and for all arguments the corresponding parameters of
F1
and
F2
have the same type:
struct A
{
A(int = 0);
};
struct B: A
{
using A::A;
B();
};
B b; // OK, B::B()
, or, if not that,
(since C++11)8) F2 is a rewritten candidate and F1 is not, or, if not that,
9) F1 and F2 are both rewritten candidates, and F2 is a synthesized rewritten candidate with reversed order of parameters and F1 is not, or, if not that,
F1
is generated from a non-template constructor and
F2
is generated from a constructor template:
template<class T>
struct A
{
using value_type = T;
A(value_type); // #1
A(const A&); // #2
A(T, T, int); // #3
template<class U>
A(int, T, U); // #4
}; // #5 is A(A), the copy deduction candidate
A x(1, 2, 3); // uses #3, generated from a non-template constructor
template<class T>
A(T) -> A<T>; // #6, less specialized than #5
A a (42); // uses #6 to deduce A<int> and #1 to initialize
A b = a; // uses #5 to deduce A<int> and #2 to initialize
template<class T>
A(A<T>) -> A<A<T>>; // #7, as specialized as #5
A b2 = a; // uses #7 to deduce A<A<int>> and #1 to initialize(since C++17)
These pair-wise comparisons are applied to all viable functions. If exactly one viable function is better than all others, overload resolution succeeds and this function is called. Otherwise, compilation fails.
void Fcn(const int*, short); // overload #1
void Fcn(int*, int); // overload #2
int i;
short s = 0;
void f()
{
Fcn(&i, 1L); // 1st argument: &i -> int* is better than &i -> const int*
// 2nd argument: 1L -> short and 1L -> int are equivalent
// calls Fcn(int*, int)
Fcn(&i, 'c'); // 1st argument: &i -> int* is better than &i -> const int*
// 2nd argument: 'c' -> int is better than 'c' -> short
// calls Fcn(int*, int)
Fcn(&i, s); // 1st argument: &i -> int* is better than &i -> const int*
// 2nd argument: s -> short is better than s -> int
// no winner, compilation error
}
If the best viable function resolves to a function for which multiple declarations were found, and if any two of these declarations inhabit different scopes and specify a default argument that made the function viable, the program is ill-formed.
namespace A
{
extern "C" void f(int = 5);
}
namespace B
{
extern "C" void f(int = 5);
}
using A::f;
using B::f;
void use()
{
f(3); // OK, default argument was not used for viability
f(); // error: found default argument twice
}[edit] Ranking of implicit conversion sequences
The argument-parameter implicit conversion sequences considered by overload resolution correspond to implicit conversions used in copy initialization (for non-reference parameters), except that when considering conversion to the implicit object parameter or to the left-hand side of assignment operator, conversions that create temporary objects are not considered. When the parameter is the implicit object parameter of a static member function, the implicit conversion sequence is a standard conversion sequence that is neither better nor worse than any other standard conversion sequence.(since C++23)
Each type of standard conversion sequence is assigned one of three ranks:
1) Exact match: no conversion required, lvalue-to-rvalue conversion, qualification conversion, function pointer conversion,(since C++17) user-defined conversion of class type to the same class
2) Promotion: integral promotion, floating-point promotion
3) Conversion: integral conversion, floating-point conversion, floating-integral conversion, pointer conversion, pointer-to-member conversion, boolean conversion, user-defined conversion of a derived class to its base
The rank of the standard conversion sequence is the worst of the ranks of the standard conversions it holds (there may be up to three conversions)
Binding of a reference parameter directly to the argument expression is either identity or a derived-to-base conversion:
struct Base {};
struct Derived : Base {} d;
int f(Base&); // overload #1
int f(Derived&); // overload #2
int i = f(d); // d -> Derived& has rank Exact Match
// d -> Base& has rank Conversion
// calls f(Derived&)
Since ranking of conversion sequences operates with types and value categories only, a bit field can bind to a reference argument for the purpose of ranking, but if that function gets selected, it will be ill-formed.
1) A standard conversion sequence is always better than a user-defined conversion sequence or an ellipsis conversion sequence.
3) A standard conversion sequence S1 is better than a standard conversion sequence S2 if
a) S1 is a proper subsequence of S2, excluding lvalue transformations; the identity conversion sequence is considered a subsequence of any non-identity conversion, or, if not that,
b) the rank of S1 is better than the rank of S2, or, if not that,
both
S1
and
S2
are binding to a reference parameter to something other than the implicit object parameter of a ref-qualified member function, and
S1
binds an rvalue reference to an rvalue while
S2
binds an lvalue reference to an rvalue:
int i; int f1(); int g(const int&); // overload #1 int g(const int&&); // overload #2 int j = g(i); // lvalue int -> const int& is the only valid conversion int k = g(f1()); // rvalue int -> const int&& better than rvalue int -> const int&
or, if not that,
d)both
S1
and
S2
are binding to a reference parameter and
S1
binds an lvalue reference to function while
S2
binds an rvalue reference to function:
int f(void(&)()); // overload #1 int f(void(&&)()); // overload #2 void g(); int i1 = f(g); // calls #1
or, if not that,
e)S1
and
S2
only differ in qualification conversion, and
the cv-qualification of the result of S1 is a proper subset of the cv-qualification of the result of S2, and S1 is not the deprecated string literal array-to-pointer conversion(until C++11).
the result of S1 can be converted to the result of S2 by a qualification conversion.
int f(const int*); int f(int*); int i; int j = f(&i); // &i -> int* is better than &i -> const int*, calls f(int*)
or, if not that,
f)both
S1
and
S2
are binding to a reference parameters only different in top-level cv-qualification, and
S1
's type is
lesscv-qualified than
S2
's:
int f(const int &); // overload #1
int f(int &); // overload #2 (both references)
int g(const int &); // overload #1
int g(int); // overload #2
int i;
int j = f(i); // lvalue i -> int& is better than lvalue int -> const int&
// calls f(int&)
int k = g(i); // lvalue i -> const int& ranks Exact Match
// lvalue i -> rvalue int ranks Exact Match
// ambiguous overload: compilation error
or, if not that,
g)S1
and
S2
bind the same reference type âreference to
T
â and have source types
V1
and
V2
, respectively, where the standard conversion sequence from
V1*to
T*is better than the standard conversion sequence from
V2*to
T*:
struct Z {};
struct A
{
operator Z&();
operator const Z&(); // overload #1
};
struct B
{
operator Z();
operator const Z&&(); // overload #2
};
const Z& r1 = A(); // OK, uses #1
const Z&& r2 = B(); // OK, uses #24)
A user-defined conversion sequence
U1
is
betterthan a user-defined conversion sequence
U2
if they call the same constructor/user-defined conversion function or initialize the same class with aggregate-initialization, and in either case the second standard conversion sequence in
U1
is better than the second standard conversion sequence in
U2
struct A
{
operator short(); // user-defined conversion function
} a;
int f(int); // overload #1
int f(float); // overload #2
int i = f(a); // A -> short, followed by short -> int (rank Promotion)
// A -> short, followed by short -> float (rank Conversion)
// calls f(int)5)
A list-initialization sequence
L1
is
betterthan list-initialization sequence
L2
if
L1
initializes an
std::initializer_listparameter, while
L2
does not.
6) A list-initialization sequence L1 is better than list-initialization sequence L2 if the corresponding parameters are references to arrays, and L1 converts to type âarray of N1 Tâ, L2 converts to âarray of N2 Tâ, and N1 is smaller than N2.
A list-initialization sequence
L1
is
betterthan list-initialization sequence
L2
if the corresponding parameters are references to arrays, and L1 and L2 convert to arrays of same element type, and either
void f(int (&&)[] ); // overload #1
void f(double (&&)[] ); // overload #2
void f(int (&&)[2]); // overload #3
f({1}); // #1: Better than #2 due to conversion, better than #3 due to bounds
f({1.0}); // #2: double -> double is better than double -> int
f({1.0, 2.0}); // #2: double -> double is better than double -> int
f({1, 2}); // #3: -> int[2] is better than -> int[],
// and int -> int is better than int -> double(since C++20)
If two conversion sequences are indistinguishable because they have the same rank, the following additional rules apply:
1) Conversion that does not involve pointer to bool or pointer-to-member to bool is better than the one that does.
2)Conversion that promotes an
enumerationwhose underlying type is fixed to its underlying type is better than one that promotes to the promoted underlying type, if the two types are different.
enum num : char { one = '0' };
std::cout << num::one; // '0', not 48(since C++11) 3)
A conversion in either direction between floating-point type
FP1
and floating-point type
FP2
is better than a conversion in the same direction between
FP1
and arithmetic type
T3
if
FP1 is equal to the rank of FP2, and
T3 is not a floating-point type, orT3 is a floating-point type whose rank is not equal to the rank of FP1, orFP2 is greater than the subrank of T3.int f(std::float32_t);
int f(std::float64_t);
int f(long long);
float x;
std::float16_t y;
int i = f(x); // calls f(std::float32_t) on implementations where
// float and std::float32_t have equal conversion ranks
int j = f(y); // error: ambiguous, no equal conversion rank(since C++23)
4) Conversion that converts pointer-to-derived to pointer-to-base is better than the conversion of pointer-to-derived to pointer-to-void, and conversion of pointer-to-base to void is better than pointer-to-derived to void.
5) If Mid is derived (directly or indirectly) from Base, and Derived is derived (directly or indirectly) from Mid
a) Derived* to Mid* is better than Derived* to Base*
b) Derived to Mid& or Mid&& is better than Derived to Base& or Base&&
c) Base::* to Mid::* is better than Base::* to Derived::*
d) Derived to Mid is better than Derived to Base
e) Mid* to Base* is better than Derived* to Base*
f) Mid to Base& or Base&& is better than Derived to Base& or Base&&
g) Mid::* to Derived::* is better than Base::* to Derived::*
h) Mid to Base is better than Derived to Base
Ambiguous conversion sequences are ranked as user-defined conversion sequences because multiple conversion sequences for an argument can exist only if they involve different user-defined conversions:
class B;
class A { A (B&);}; // converting constructor
class B { operator A (); }; // user-defined conversion function
class C { C (B&); }; // converting constructor
void f(A) {} // overload #1
void f(C) {} // overload #2
B b;
f(b); // B -> A via ctor or B -> A via function (ambiguous conversion)
// b -> C via ctor (user-defined conversion)
// the conversions for overload #1 and for overload #2
// are indistinguishable; compilation fails[edit] Implicit conversion sequence in list-initialization
In list initialization, the argument is a braced-init-list, which isn't an expression, so the implicit conversion sequence into the parameter type for the purpose of overload resolution is decided by the following special rules:
X and the initializer list consists of exactly one element of same or derived class (possibly cv-qualified), the implicit conversion sequence is the one required to convert the element to the parameter type.X, the implicit conversion sequence for the purpose of overload resolution is the worst conversion necessary. If the braced-init-list is empty, the conversion sequence is the identity conversion.{} if the list is shorter than N) to T is the one used.T is the one used.typedef int IA[3];
void h(const IA&);
void g(int (&&)[]);
h({1, 2, 3}); // int->int identity conversion
g({1, 2, 3}); // same as above since C++20
X, overload resolution picks the constructor C of X to initialize from the argument initializer listIf multiple constructors are viable but none is better than the others, the implicit conversion sequence is the ambiguous conversion sequence.
struct A { A(std::initializer_list<int>); };
void f(A);
struct B { B(int, double); };
void g(B);
g({'a', 'b'}); // calls g(B(int, double)), user-defined conversion
// g({1.0, 1,0}); // error: double->int is narrowing, not allowed in list-init
void f(B);
// f({'a', 'b'}); // f(A) and f(B) both user-defined conversions
struct A { int m1; double m2; };
void f(A);
f({'a', 'b'}); // calls f(A(int, double)), user-defined conversion
struct A { int m1; double m2; };
void f(const A&);
f({'a', 'b'}); // temporary created, f(A(int, double)) called. User-defined conversion
If the argument is a designated initializer list and the parameter is not a reference, a conversion is only possible if the parameter has an aggregate type that can be initialized from that initializer list according to the rules for aggregate initialization, in which case the implicit conversion sequence is a user-defined conversion sequence whose second standard conversion sequence is an identity conversion.
If, after overload resolution, the order of declaration of the aggregate's members does not match for the selected overload, the initialization of the parameter will be ill-formed.
struct A { int x, y; };
struct B { int y, x; };
void f(A a, int); // #1
void f(B b, ...); // #2
void g(A a); // #3
void g(B b); // #4
void h()
{
f({.x = 1, .y = 2}, 0); // OK; calls #1
f({.y = 2, .x = 1}, 0); // error: selects #1, initialization of a fails
// due to non-matching member order
g({.x = 1, .y = 2}); // error: ambiguous between #3 and #4
}(since C++20) [edit] Defect reports
The following behavior-changing defect reports were applied retroactively to previously published C++ standards.
DR Applied to Behavior as published Correct behavior CWG 1 C++98 the behavior was unspecified when the sameF contains
&F(args) only invalid if overload
@
T1 was empty if
T1 is a class currently being defined the set is the result of
T1::operator@ in this case CWG 1687 C++98 when a built-in candidate is selected by overload resolution,
X from {X} non-aggregates consider
Tâ. References of this type cannot bound to a temporary.RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4