A call to a
function selects from all functions that
overload the specified function name. The selection
process involves considering all functions of the given name (in the current
scope) for which conversions exist from the
calling parameter list to the function's formal parameter list.
The function whose formal parameter list *best matches* the calling parameter list is selected.
The *best matching* function is defined to be the intersection of the sets of eligible
functions that best match on each parameter. If the intersection is empty then the call
cannot be matched. The call is ambiguous unless the intersection consists of
exactly one function; that is, unless a function can be found that is a better
match on a particular parameter than all other functions in the sets being
intersected.

The following considerations apply to parameter matching.

- For the purposes of parameter matching, a function with n default parameters is considered to be n+1 functions, each with a different number of parameters.
- When an ellipsis is encountered in the declaration of an eligible function, it is considered to match parameters of any type.
- For the purposes of parameter matching, a non-static
method is considered to have an
*additional parameter*that specifies the instance for which the method is invoked (see the this pointer). This additional parameter requires specification via a member access operator, or via the first parameter of an overloaded operator. The type of the additional parameter must be matched. No temporaries are introduced for the additional parameter and no application defined conversions are used. - When a non-static method of class X is called through the
operator ->, the additional parameter is assumed
to be of type
*const X**for constant methods, of type*volatile X**for volatile methods and to be of type*X**for non-constant, non-volatile methods. - When a non-static method of class X is called through the
operator . or as the first operand of an
overloaded operator, the additional parameter is assumed
to be of type
*const X&*for constant methods, of type*volatile X&*for volatile methods and to be of type*X&*for non-constant, non-volatile methods. The first operand of the pointer to member operators ->* and .* is treated in the same way as the first operand of operators -> and . (respectively). - For a parameter specified in a function call, at most one application defined conversion is considered when attempting to match the parameter with the formal parameter of a candidate function.
- When standard conversions are applied, only the
shortest sequence leading from the type of the actual parameter to the type of the formal
parameter is considered. The shortest conversion sequence is called the
*best matching sequence*. For example, int->double is a better match than int->float->double. - Apart from the exceptions mentioned shortly, the following
*trivial conversions*involving type T do not influence which of two conversions is considered to be better.

From To From To T T& T& T T[] T* T(params) T(*)(params) T const T T volatile T T* const T* T* volatile T* - Sequences of trivial conversions that differ only in the order of their
occurrence are indistinguishable. Parameters of type
*T*,*const T*,*volatile T*,*T&*,*const T&*and*volatile T&*accept the same initializers. As stated in the rules that follow, the constant and volatile type specifiers may be used as tie breakers in the parameter matching process. - A temporary is required when the formal parameter of a function is of type
*T&*and the actual parameter supplied to the function call is either not an lvalue, is not of type*T*or is of type*volatile T.*Parameter matching is unaffected by the introduction of such temporaries; however, it is illegal to attempt to initialize a non-constant reference with a temporary.

The following rules are applied to conversion sequences.

A sequence with zero or more *trivial conversions* is considered superior to all
other conversion sequences. An exact match sequence that does not convert *T** to
*const T** or to *volatile T** is superior to one that does. An exact match sequence that
does not convert *T&* to *const T&* or to *volatile T&* is superior to
one that does.

Amongst sequences that are not an *exact match*, sequences that perform only
trivial conversions, integral promotions and conversions
from float to double are considered superior to all
the rest.

Amongst sequences that are not an *exact match* or a *match with promotions*,
sequences that perform only trivial and standard conversions
are considered superior to all the rest. Of matches with standard
conversions, sequences with conversions of the form D* to B* (where D derives publicly
from B) are considered superior to sequences converting D* to void* or D* to const
void*. Also, if C publicly derives from B and B publicly derives from A then a
conversion of the form C* to B* is superior to a conversion of the form C* to
A*. Similarly, a conversion of the form C& to B& is superior to a conversion of
the form C& to A&. Pointer to member
conversions are subject to the same considerations with regard to the inheritance hierarchy.

Amongst sequences that are not an *exact match*, a *match with promotions*
or a *match with standard conversions*, sequences that perform only trivial, standard and
application defined conversions are considered superior
to all the rest.

Sequences that involve matching with an ellipsis are considered to be inferior to all other conversion sequences.

The following facts also apply to conversions when used in parameter matching.

- A standard conversion may be combined with an application defined conversion (in either order).
- If an explicit conversion or
type cast is
*required*to prevent ambiguity then no account is taken of possible best match sequences of standard conversions that may be implicitly applied to obtain a match. - No preference is given to conversion operators over conversion by constructor (and vice-versa).

The following example demonstrates the selection of application defined conversions.

class test { public: operator int(); // Conversion tointoperator double(); // Conversion todouble... } instance; // Declare an instance of test. int i = instance; // Calls test::operator int(). double n = instance; // Calls test::operator double(). float f = instance; // Error ! Ambiguity between // test::operator int() and test::operator double()

The next example demonstrates the point that standard conversions may be applied in addition to application defined conversions (in either order).

class test { public: test(long); // Constructor acceptinglongoperator int(); // Conversion toint... } instance; // Declare an instance of test. void f(long); void g(const test&); f(instance); // Same as: f(long((int)instance)); g(0); // Same as: g(test(long(0)));

The following example demonstrates the point that if an
explicit conversion or
type cast is *required* to prevent ambiguity then no
account is taken of possible best match sequences of
standard conversions that may be implicitly used to obtain
a match.

class A { public: A(int); // Constructor acceptingint}; class B { public: B(long); // Constructor acceptinglong}; void f(A); void f(B); f(1); // Ambiguous despite the fact that f(B(long(1)) // requires one more standard conversion than f(A(1)).

The following example illustrates the fact that *conversions by constructor*
are not given precedence over *conversion operators* and vice-versa.

class A { public: operator int(); // conversion operator ... }; class B { public: B(const A&); // conversion constructor. ... }; B operator*(const B&,const B&); void f(const A& A1, const A& A2) { A1 * A2; // Error: Ambiguous - could be interpreted as either // operator*(B(A1),B(A2)) or as // (int)A1 * (int)A2 }