\rSec0[over]{Overloading}%

\indextext{overloading|(}

\indextext{declaration!overloaded}%

\indextext{overloaded function|see{overloading}}%

\indextext{function, overloaded|see{overloading}}%

When two or more different declarations are specified for a single name

in the same scope, that name is said to be

\grammarterm{overloaded}.

By extension, two declarations in the same scope that declare the same name

but with different types are called

\term{overloaded declarations}.

Only function and function template

declarations can be overloaded; variable and type declarations

cannot be overloaded.

When an overloaded function name is used in a call, which overloaded function

declaration is being referenced is determined by comparing the types

of the arguments at the point of use with the types of the parameters

in the overloaded declarations that are visible at the point of use.

This function selection process is called

\term{overload resolution}

and

is defined in~\ref{over.match}.

\indextext{overloading!example of}%

\begin{codeblock}

double abs(double);

int abs(int);

abs(1); // calls \tcode{abs(int);}

abs(1.0); // calls \tcode{abs(double);}

\end{codeblock}

\rSec1[over.load]{Overloadable declarations}

\indextext{overloading!declarations}%

\indextext{overloading!prohibited}%

Not all function declarations can be overloaded.

Those that cannot be

overloaded are specified here.

A program is ill-formed if it contains

two such non-overloadable declarations in the same scope.

This restriction applies to explicit declarations in a scope, and between

such declarations and

declarations made through a

\grammarterm{using-declaration}~(\ref{namespace.udecl}).

It does not apply to sets of functions fabricated as a result of

name lookup (e.g., because of

\grammarterm{using-directive}{s})

or overload resolution

(e.g., for operator functions).

Certain function declarations cannot be overloaded:

\begin{itemize}

\indextext{return~type!overloading~and}%

Function declarations that differ only in the return type cannot be

overloaded.

\indextext{\idxcode{static}!overloading~and}%

Member function declarations with the same name and the same

\grammarterm{parameter-type-list} cannot be overloaded if any of them is a

\tcode{static}

member function declaration~(\ref{class.static}).

Likewise, member function template declarations with the same name,

the same \grammarterm{parameter-type-list}, and the same template parameter lists cannot be

overloaded if any of them is a

\tcode{static}

member function template declaration.

The types of the implicit object parameters constructed for the member

functions for the purpose of overload resolution~(\ref{over.match.funcs})

are not considered when comparing parameter-type-lists for enforcement of

this rule.

In contrast, if there is no

\tcode{static}

member function declaration among a set of member function

declarations with the same name and the same parameter-type-list, then

these member function declarations can be overloaded if they differ in

the type of their implicit object parameter.

the following illustrates this distinction:

\begin{codeblock}

class X {

static void f();

void f(); // ill-formed

void f() const; // ill-formed

void f() const volatile; // ill-formed

void g();

void g() const; // OK: no static \tcode{g}

void g() const volatile; // OK: no static \tcode{g}

};

\end{codeblock}

\item Member function declarations with the same name and the same

\grammarterm{parameter-type-list} as well as member function template

declarations with the same name, the same \grammarterm{parameter-type-list}, and

the same template parameter lists cannot be overloaded if any of them, but not

all, have a \grammarterm{ref-qualifier}~(\ref{dcl.fct}). \enterexample

\begin{codeblock}

class Y {

void h() &;

void h() const &; // OK

void h() &&; // OK, all declarations have a ref-qualifier

void i() &;

void i() const; // ill-formed, prior declaration of \tcode{i}

// has a ref-qualifier

};

\end{codeblock}

\end{itemize}

\indextext{equivalent~parameter~declarations}%

\indextext{equivalent~parameter~declarations!overloading~and}%

As specified in~\ref{dcl.fct},

function declarations that have equivalent parameter declarations declare

the same function and therefore cannot

be overloaded:

\begin{itemize}

\indextext{\idxcode{typedef}!overloading~and}%

Parameter declarations that differ only in the use of equivalent typedef

``types'' are equivalent.

A

\tcode{typedef}

is not a separate type, but only a synonym for another type~(\ref{dcl.typedef}).

\begin{codeblock}

typedef int Int;

void f(int i);

void f(Int i); // OK: redeclaration of \tcode{f(int)}

void f(int i) @\tcode{\{ /* ... */ \}}@

void f(Int i) @\tcode{\{ /* ... */ \}}@ // error: redefinition of \tcode{f(int)}

\end{codeblock}

\indextext{\idxcode{enum}!overloading~and}%

Enumerations, on the other hand, are distinct types and can be used to

distinguish

overloaded function declarations.

\begin{codeblock}

enum E { a };

void f(int i) @\tcode{\{ /* ... */ \}}@

void f(E i) @\tcode{\{ /* ... */ \}}@

\end{codeblock}

\indextext{array!overloading~and pointer~versus}%

Parameter declarations that differ only in a pointer

\tcode{*}

versus an array

\tcode{[]}

are equivalent.

That is, the array declaration is adjusted to become a pointer

declaration~(\ref{dcl.fct}).

Only the second and subsequent array dimensions are significant in

parameter types~(\ref{dcl.array}).

\begin{codeblock}

int f(char*);

int f(char[]); // same as \tcode{f(char*);}

int f(char[7]); // same as \tcode{f(char*);}

int f(char[9]); // same as \tcode{f(char*);}

int g(char(*)[10]);

int g(char[5][10]); // same as \tcode{g(char(*)[10]);}

int g(char[7][10]); // same as \tcode{g(char(*)[10]);}

int g(char(*)[20]); // different from \tcode{g(char(*)[10]);}

\end{codeblock}

Parameter declarations that differ only in that one is a function type

and the other is a pointer to the same function type are equivalent.

That is, the function type is adjusted to become a pointer to function type~(\ref{dcl.fct}).

\begin{codeblock}

void h(int());

void h(int (*)()); // redeclaration of \tcode{h(int())}

void h(int x()) { } // definition of \tcode{h(int())}

void h(int (*x)()) { } // ill-formed: redefinition of \tcode{h(int())}

\end{codeblock}

\indextext{\idxcode{const}!overloading~and}%

\indextext{\idxcode{volatile}!overloading~and}%

Parameter declarations that differ only in the presence or absence of

\tcode{const}

and/or

\tcode{volatile}

are equivalent.

That is, the

\tcode{const}

and

\tcode{volatile}

type-specifiers for

each parameter type are ignored when determining which function is being

declared,

defined, or called.

\begin{codeblock}

typedef const int cInt;

int f (int);

int f (const int); // redeclaration of \tcode{f(int)}

int f (int) @\tcode{\{ /* ... */ \}}@ // definition of \tcode{f(int)}

int f (cInt) @\tcode{\{ /* ... */ \}}@ // error: redefinition of \tcode{f(int)}

\end{codeblock}

Only the

\tcode{const}

and

\tcode{volatile}

type-specifiers at the outermost level of the

parameter type specification are ignored in this fashion;

\tcode{const}

and

\tcode{volatile}

type-specifiers buried within a parameter type specification are significant

and can be used to distinguish overloaded function

declarations.\footnote{When a parameter type includes a function type,

such as in the case of a parameter type that is a pointer to function, the

\tcode{const}

and

\tcode{volatile}

type-specifiers at the outermost level of the parameter type

specifications for the inner function type are also ignored.}

In particular, for any type

\tcode{T},

and

are considered distinct parameter types, as are

and

\indextext{default~initializers!overloading~and}%

Two parameter declarations that differ only in their default arguments

are equivalent.

consider the following:

\begin{codeblock}

void f (int i, int j);

void f (int i, int j = 99); // OK: redeclaration of \tcode{f(int, int)}

void f (int i = 88, int j); // OK: redeclaration of \tcode{f(int, int)}

void f (); // OK: overloaded declaration of \tcode{f}

void prog () {

f (1, 2); // OK: call \tcode{f(int, int)}

f (1); // OK: call \tcode{f(int, int)}

f (); // Error: \tcode{f(int, int)} or \tcode{f()}?

}

\end{codeblock}

\end{itemize}

\rSec1[over.dcl]{Declaration matching}%

\indextext{overloading!declaration matching}%

\indextext{scope!overloading and}%

\indextext{base class!overloading and}

Two function declarations of the same name refer to the same function if they

are in the same scope and have equivalent parameter declarations~(\ref{over.load}).

A function member of a derived class is

\textit{not}

in the same scope as a function member of the same name in a base class.

\begin{codeblock}

struct B {

int f(int);

};

struct D : B {

int f(const char*);

};

\end{codeblock}

\indextext{name hiding!function}%

\indextext{name hiding!overloading versus}%

Here

\tcode{D::f(const char*)}

hides

\tcode{B::f(int)}

rather than overloading it.

\indextext{Ben}%

\begin{codeblock}

void h(D* pd) {

pd->f(1); // error:

// \tcode{D::f(const char*)} hides \tcode{B::f(int)}

pd->B::f(1); // OK

pd->f("Ben"); // OK, calls \tcode{D::f}

}

\end{codeblock}

A locally declared function is not in the same scope as a function in

a containing scope.

\begin{codeblock}

void f(const char*);

void g() {

extern void f(int);

f("asdf"); // error: \tcode{f(int)} hides \tcode{f(const char*)}

// so there is no \tcode{f(const char*)} in this scope

}

void caller () {

extern void callee(int, int);

{

extern void callee(int); // hides \tcode{callee(int, int)}

callee(88, 99); // error: only \tcode{callee(int)} in scope

}

}

\end{codeblock}

\indextext{access control!overloading and}%

\indextext{overloading!access control and}%

Different versions of an overloaded member function can be given different

access rules.

\begin{codeblock}

class buffer {

private:

char* p;

int size;

protected:

buffer(int s, char* store) { size = s; p = store; }

public:

buffer(int s) { p = new char[size = s]; }

};

\end{codeblock}

\rSec1[over.match]{Overload resolution}%

\indextext{overloading!resolution|(}%

\indextext{resolution|see{overloading, resolution}}%

\indextext{ambiguity!overloaded function}

Overload resolution is a mechanism for selecting the best

function to call given a list of expressions that are to be the

arguments of the call and a set of

\term{candidate functions}

that can

be called based on the context of the call.

The selection

criteria for the best function are the number of arguments, how

well the arguments match the parameter-type-list of the

candidate function,

how well (for non-static member functions) the object

matches the implicit object parameter,

and certain other properties of the candidate function.

The function selected by overload resolution is not

guaranteed to be appropriate for the context.

Other restrictions,

such as the accessibility of the function, can make its use in

the calling context ill-formed.

\indextext{overloading!resolution!contexts}%

Overload resolution selects the function to call in seven distinct

contexts within the language:

\begin{itemize}

invocation of a function named in the function call syntax~(\ref{over.call.func});

invocation of a function call operator, a pointer-to-function

conversion function, a reference-to-pointer-to-function conversion

function, or a reference-to-function

conversion function on a class object named in the function

call syntax~(\ref{over.call.object});

invocation of the operator referenced in an expression~(\ref{over.match.oper});

invocation of a constructor for default- or direct-initialization~(\ref{dcl.init})

of a class object~(\ref{over.match.ctor});

invocation of a user-defined conversion for

copy-initialization~(\ref{dcl.init}) of a class object~(\ref{over.match.copy});

invocation of a conversion function for initialization of an object of a

nonclass type from an expression of class type~(\ref{over.match.conv}); and

invocation of a conversion function for conversion to a glvalue

or class prvalue

to which a reference~(\ref{dcl.init.ref})

will be directly bound~(\ref{over.match.ref}).

\end{itemize}

Each of these contexts defines the set of candidate functions and

the list of arguments in its own unique way.

But, once the

candidate functions and argument lists have been identified, the

selection of the best function is the same in all cases:

\begin{itemize}

First, a subset of the candidate functions (those that have

the proper number of arguments and meet certain other

conditions) is selected to form a set of

\indextext{function!viable}%

viable functions~(\ref{over.match.viable}).

Then the best viable function is selected based on the

implicit conversion sequences~(\ref{over.best.ics}) needed to

match each argument to the corresponding parameter of each

viable function.

\end{itemize}

If a best viable function exists and is unique, overload

resolution succeeds and produces it as the result.

Otherwise

overload resolution fails and the invocation is ill-formed.

When overload resolution succeeds,

and the best viable function is not accessible (Clause~\ref{class.access}) in the context

in which it is used,

the program is ill-formed.

\rSec2[over.match.funcs]{Candidate functions and argument lists}%

\indextext{overloading!candidate functions|(}%

\indextext{overloading!argument lists|(}

The subclauses of~\ref{over.match.funcs} describe

the set of candidate functions and the argument list submitted to

overload resolution in each of the seven contexts in which

overload resolution is used.

The source transformations and constructions defined

in these subclauses are only for the purpose of describing the

overload resolution process.

An implementation is not required

to use such transformations and constructions.

\indextext{member function!overload resolution and}%

\indextext{function!overload resolution and}%

The set of candidate functions can contain both member and non-member

functions to be resolved against the same argument list.

So that argument and parameter lists are comparable within this

heterogeneous set, a member function is considered to have an

extra parameter, called the

\defn{implicit object parameter},

which represents the object for which the member function has been

called.

For the purposes of overload resolution, both static and

non-static member functions have an implicit object parameter,

but constructors do not.

Similarly, when appropriate, the context can construct an

argument list that contains an

\defn{implied object argument}

to denote

the object to be operated on.

Since arguments and parameters are

associated by position within their respective lists, the

convention is that the implicit object parameter, if present, is

always the first parameter and the implied object argument, if

present, is always the first argument.

For non-static member functions, the type of the implicit object

parameter is

\begin{itemize}

\item ``lvalue reference to \textit{cv} \tcode{X}'' for functions declared

without a \grammarterm{ref-qualifier} or with the

\tcode{\&} \grammarterm{ref-qualifier}

\item ``rvalue reference to \textit{cv} \tcode{X}'' for functions declared with the

\tcode{\&\&} \grammarterm{ref-qualifier}

\end{itemize}

where

\tcode{X}

is the class of which the function is a member and

\textit{cv}

is the cv-qualification on the

member function declaration.

for a

\tcode{const}

member

function of class

\tcode{X},

the extra parameter is assumed to have type

\tcode{const X}''.

For conversion functions, the function is considered to be a member of the

class of the implied object argument for the purpose of defining the

type of the implicit object parameter.

For non-conversion functions

introduced by a

\grammarterm{using-declaration}

into a derived class, the function is

considered to be a member of the derived class for the purpose of defining

the type of the implicit object parameter.

For static member functions, the implicit object parameter is considered

to match any object (since if the function is selected, the object is

discarded).

No actual type is established for the implicit object parameter

of a static member function, and no attempt will be made to determine a

conversion sequence for that parameter~(\ref{over.match.best}).

\indextext{implied object argument!implicit conversion sequences}%

During overload resolution, the implied object argument is

indistinguishable from other arguments.

The implicit object

parameter, however, retains its identity since conversions on the

corresponding argument shall obey these additional rules:

\begin{itemize}

no temporary object can be introduced to hold the argument

for the implicit object parameter; and

no user-defined conversions can be applied to achieve a type

match with it.

\end{itemize}

\indextext{implied object argument!non-static member function and}%

For non-static member functions declared without a \grammarterm{ref-qualifier},

an additional rule applies:

\begin{itemize}

even if the implicit object parameter is not

\tcode{const}-qualified,

an rvalue can be bound to the parameter

as long as in all other respects the argument can be

converted to the type of the implicit object parameter.

\enternote The fact that such an argument is an rvalue does not

affect the ranking of implicit conversion sequences~(\ref{over.ics.rank}).

\end{itemize}

Because other than in list-initialization only one user-defined conversion

is allowed

in an

implicit conversion sequence, special rules apply when selecting

the best user-defined conversion~(\ref{over.match.best},

\ref{over.best.ics}).

\begin{codeblock}

class T {

public:

T();

};

class C : T {

public:

C(int);

};

T a = 1; // ill-formed: \tcode{T(C(1))} not tried

\end{codeblock}

In each case where a candidate is a function template, candidate

function template specializations

are generated using template argument deduction~(\ref{temp.over},

\ref{temp.deduct}).

Those candidates are then handled as candidate

functions in the usual way.\footnote{The process of argument deduction fully

determines the parameter types of

the

function template specializations,

i.e., the parameters of

function template specializations

contain

no template parameter types.

Therefore, except where specified otherwise,

function template specializations

and non-template functions~(\ref{dcl.fct}) are treated equivalently

for the remainder of overload resolution.}

A given name can refer to one or more function templates and also

to a set of overloaded non-template functions.

In such a case, the

candidate functions generated from each function template are combined

with the set of non-template candidate functions.

A defaulted move constructor or assignment operator~(\ref{class.copy}) that is

defined as deleted is excluded from the set of candidate functions in all

contexts.

\rSec3[over.match.call]{Function call syntax}%

\indextext{overloading!resolution!function call syntax|(}

In a function call~(\ref{expr.call})

\begin{ncsimplebnf}

postfix-expression \terminal{(} expression-list\opt \terminal{)}

\end{ncsimplebnf}

if the \grammarterm{postfix-expression} denotes a set of overloaded functions and/or

function templates, overload resolution is applied as specified in \ref{over.call.func}.

If the \grammarterm{postfix-expression} denotes an object of class type, overload

resolution is applied as specified in \ref{over.call.object}.

If the \grammarterm{postfix-expression} denotes the address of a set of overloaded

functions and/or function templates, overload resolution is applied using that set as

described above. If the function selected by overload resolution is a non-static member

function, the program is ill-formed. \enternote The resolution of the address of an

overload set in other contexts is described in \ref{over.over}. \exitnote

\rSec4[over.call.func]{Call to named function}

Of interest in~\ref{over.call.func} are only those function calls in

which the

\grammarterm{postfix-expression}

ultimately contains a name that

denotes one or more functions that might be called.

Such a

\grammarterm{postfix-expression},

perhaps nested arbitrarily deep in

parentheses, has one of the following forms:

\begin{ncbnf}

postfix-expression:\br

postfix-expression \terminal{.} id-expression\br

postfix-expression \terminal{->} id-expression\br

primary-expression

\end{ncbnf}

These represent two syntactic subcategories of function calls:

qualified function calls and unqualified function calls.

In qualified function calls, the name to be resolved is an

\grammarterm{id-expression}

and is preceded by an

\tcode{->}

or

\tcode{.}

operator.

Since the

construct

\tcode{A->B}

is generally equivalent to

\tcode{(*A).B},

the rest of

Clause~\ref{over} assumes, without loss of generality, that all member

function calls have been normalized to the form that uses an

object and the

\tcode{.}

operator.

Furthermore, Clause~\ref{over} assumes that

the

\grammarterm{postfix-expression}

that is the left operand of the

\tcode{.}

operator

has type ``\textit{cv}

where

\tcode{T}

denotes a class\footnote{Note that cv-qualifiers on the type of objects are

significant in overload

resolution for

both glvalue and class prvalue objects.}.

Under this

assumption, the

\grammarterm{id-expression}

in the call is looked up as a

member function of

\tcode{T}

following the rules for looking up names in

classes~(\ref{class.member.lookup}).

The function declarations found by that lookup constitute the set of

candidate functions.

The argument list is the

\grammarterm{expression-list}

in the call augmented by the addition of the left operand of

the

\tcode{.}

operator in the normalized member function call as the

implied object argument~(\ref{over.match.funcs}).

In unqualified function calls, the name is not qualified by an

\tcode{->}

or

\tcode{.}

operator and has the more general form of a

\grammarterm{primary-expression}.

The name is looked up in the context of the function

call following the normal rules for name lookup in function

calls~(\ref{basic.lookup}).

The function declarations found by that lookup constitute the

set of candidate functions.

Because of the rules for name lookup, the set of candidate functions

consists (1) entirely of non-member functions or (2) entirely of

member functions of some class

\tcode{T}.

In case (1),

the argument list is

the same as the

\grammarterm{expression-list}

in the call.

In case (2), the argument list is the

\grammarterm{expression-list}

in the call augmented by the addition of an implied object

argument as in a qualified function call.

If the keyword

\tcode{this}~(\ref{class.this}) is in scope and refers to

class

\tcode{T},

or a derived class of

\tcode{T},

then the implied object argument is

\tcode{(*this)}.

If the keyword

\tcode{this}

is not in

scope or refers to another class, then

a contrived object of type

\tcode{T}

becomes the implied object

argument\footnote{An implied object argument must be contrived to

correspond to the implicit object

parameter attributed to member functions during overload resolution.

It is not

used in

the call to the selected function.

Since the member functions all have the

same implicit

object parameter, the contrived object will not be the cause to select or

reject a

function.}.

If the argument list is augmented by a contrived object and overload

resolution selects one of the non-static member functions of

\tcode{T},

the call is ill-formed.

\rSec4[over.call.object]{Call to object of class type}

If the

\grammarterm{primary-expression}

\tcode{E}

in the function call syntax evaluates

to a class object of type ``\textit{cv}

\tcode{T}'',

then the set of candidate

functions includes at least the function call operators of

\tcode{T}.

The

function call operators of

\tcode{T}

are obtained by ordinary lookup of

the name

\tcode{operator()}

in the context of

\tcode{(E).operator()}.

In addition, for each non-explicit conversion function declared in \tcode{T} of the

form

\begin{ncsimplebnf}

\terminal{operator} conversion-type-id \terminal{(\,)} cv-qualifier ref-qualifier\opt exception-specification\opt attribute-specifier-seq\opt \terminal{;}

\end{ncsimplebnf}

where

\grammarterm{cv-qualifier}

is the same cv-qualification as, or a greater cv-qualification than,

\textit{cv},

and where

\grammarterm{conversion-type-id}

denotes the type ``pointer to function

of (\tcode{P1},...,\tcode{Pn)} returning \tcode{R}'',

or the type ``reference to pointer to function

of (\tcode{P1},...,\tcode{Pn)} returning \tcode{R}'',

or the type

returning \tcode{R}'', a \term{surrogate call function} with the unique name

\grammarterm{call-function}

and having the form

\begin{ncbnf}

\terminal{R} call-function \terminal{(} conversion-type-id \terminal{F, P1 a1, ... ,Pn an)} \terminal{\{ return F (a1,... ,an); \}}

\end{ncbnf}

is also considered as a candidate function.

Similarly, surrogate

call functions are added to the set of candidate functions for

each non-explicit conversion function declared in a base class of

\tcode{T}

provided the function is not hidden within

\tcode{T}

by another

intervening declaration\footnote{Note that this construction can yield

candidate call functions that cannot be

differentiated one from the other by overload resolution because they have

identical

declarations or differ only in their return type.

The call will be ambiguous

if overload

resolution cannot select a match to the call that is uniquely better than such

undifferentiable functions.}.

If such a surrogate call function is selected by overload

resolution, the corresponding conversion function will be called to convert

\tcode{E}

to the appropriate function pointer or reference, and the function

will then be invoked with the arguments of the call. If the

conversion function cannot be called (e.g., because of an ambiguity),

the program is ill-formed.

The argument list submitted to overload resolution consists of

the argument expressions present in the function call syntax

preceded by the implied object argument

\tcode{(E)}.

When comparing the

call against the function call operators, the implied object

argument is compared against the implicit object parameter of the

function call operator.

When comparing the call against a

surrogate call function, the implied object argument is compared

against the first parameter of the surrogate call function.

The

conversion function from which the surrogate call function was

derived will be used in the conversion sequence for that

parameter since it converts the implied object argument to the

appropriate function pointer or reference required by that first

parameter.

\begin{codeblock}

int f1(int);

int f2(float);

typedef int (*fp1)(int);

typedef int (*fp2)(float);

struct A {

operator fp1() { return f1; }

operator fp2() { return f2; }

} a;

int i = a(1); // calls \tcode{f1} via pointer returned from

// conversion function

\end{codeblock}

\indextext{overloading!resolution!function call syntax|)}

\rSec3[over.match.oper]{Operators in expressions}%

\indextext{overloading!resolution!operators}

If no operand of an operator in an expression has a type that is a class

or an enumeration, the operator is assumed to be a built-in operator

and interpreted according to Clause~\ref{expr}.

Because

\tcode{.},

\tcode{.*},

and

\tcode{::}

cannot be overloaded,

these operators are always built-in operators interpreted according to

Clause~\ref{expr}.

\tcode{?:}

cannot be overloaded, but the rules in this subclause are used to determine

the conversions to be applied to the second and third operands when they

have class or enumeration type~(\ref{expr.cond}).

\begin{codeblock}

struct String {

String (const String&);

String (const char*);

operator const char* ();

};

String operator + (const String&, const String&);

void f(void) {

const char* p= "one" + "two"; // ill-formed because neither

// operand has class or enumeration type

int I = 1 + 1; // Always evaluates to \tcode{2} even if

// class or enumeration types exist that

// would perform the operation.

}

\end{codeblock}

If either operand has a type that is a class or an enumeration, a

user-defined operator function might be declared that implements

this operator or a user-defined conversion can be necessary to

convert the operand to a type that is appropriate for a built-in

operator.

In this case, overload resolution is used to determine

which operator function or built-in operator is to be invoked to implement the

operator.

Therefore, the operator notation is first transformed

to the equivalent function-call notation as summarized in

Table~\ref{tab:over.rel.op.func}

(where \tcode{@} denotes one of the operators covered in the specified subclause).

\begin{floattable}{Relationship between operator and function call notation}{tab:over.rel.op.func}

{l|m|m|m}

\hdstyle{Subclause} & \hdstyle{Expression} & \hdstyle{As member function} & \hdstyle{As non-member function} \\ \capsep

\ref{over.unary} & @a & (a).operator@ (\,) & operator@ (a) \\

\ref{over.binary} & a@b & (a).operator@ (b) & operator@ (a, b) \\

\ref{over.ass} & a=b & (a).operator= (b) & \\

\ref{over.sub} & a[b] & (a).operator[](b) & \\

\ref{over.ref} & a-> & (a).operator-> (\,) & \\

\ref{over.inc} & a@ & (a).operator@ (0) & operator@ (a, 0) \\

\end{floattable}

For a unary operator

\tcode{@}

with an operand of a type whose cv-unqualified version is

\tcode{T1},

and for a binary operator

\tcode{@}

with a left operand of a type whose cv-unqualified version is

\tcode{T1}

and a right operand of a type whose cv-unqualified version is

\tcode{T2},

three sets of candidate functions, designated

\term{member candidates},

\term{non-member candidates}

and

\term{built-in candidates},

are constructed as follows:

\begin{itemize}