From fad3c1dae5aa66566d7ddac82b0065cf60c18d88 Mon Sep 17 00:00:00 2001 From: Richard Smith Date: Sun, 30 Jul 2017 23:31:44 -0700 Subject: [PATCH 01/79] Update configuration for building drafts after N4687. --- source/config.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/source/config.tex b/source/config.tex index d96308e84a..e5fea1bf09 100644 --- a/source/config.tex +++ b/source/config.tex @@ -1,8 +1,8 @@ %!TEX root = std.tex %%-------------------------------------------------- %% Version numbers -\newcommand{\docno}{N4687} -\newcommand{\prevdocno}{N4659} +\newcommand{\docno}{Dxxxx} +\newcommand{\prevdocno}{N4687} \newcommand{\cppver}{201703L} %% Release date From 8994e078b2ce128a4679ae5c3b3eb9bb2e7dc12b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thomas=20K=C3=B6ppe?= Date: Mon, 31 Jul 2017 13:37:26 +0100 Subject: [PATCH 02/79] [dcl.arrays] Remove redundant whitespace --- source/declarators.tex | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/source/declarators.tex b/source/declarators.tex index f148e29f1e..1777be86bc 100644 --- a/source/declarators.tex +++ b/source/declarators.tex @@ -1094,7 +1094,6 @@ \begin{codeblock} float fa[17], *afp[17]; \end{codeblock} - declares an array of \tcode{float} numbers and an array of @@ -1108,7 +1107,6 @@ \begin{codeblock} int x3d[3][5][7]; \end{codeblock} - declares an array of three elements, each of which is an array of five elements, each of which is an array of seven integers. @@ -1127,7 +1125,7 @@ is equivalent to \tcode{*(x3d + i)}; in that expression, -\tcode{x3d} +\tcode{x3d} is subject to the array-to-pointer conversion\iref{conv.array} and is first converted to a pointer to a 2-dimensional From 78f8e15e9acb75272c0c32cd7df9085e81668b1e Mon Sep 17 00:00:00 2001 From: Eelis van der Weegen Date: Mon, 31 Jul 2017 15:19:03 +0200 Subject: [PATCH 03/79] Remove accidentally committed tmp.tex. --- source/tmp.tex | 3785 ------------------------------------------------ 1 file changed, 3785 deletions(-) delete mode 100644 source/tmp.tex diff --git a/source/tmp.tex b/source/tmp.tex deleted file mode 100644 index 636a32d0d6..0000000000 --- a/source/tmp.tex +++ /dev/null @@ -1,3785 +0,0 @@ -%!TEX root = std.tex -\rSec0[over]{Overloading}% -\indextext{overloading|(} - -\gramSec[gram.over]{Overloading} - -\pnum -\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. - -\pnum -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}. -\begin{example} - -\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} -\end{example} - -\rSec1[over.load]{Overloadable declarations} -\indextext{overloading!declarations}% - -\pnum -\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. -\begin{note} -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). -\end{note} - -\pnum -Certain function declarations cannot be overloaded: - -\begin{itemize} -\item -\indextext{return type!overloading and}% -Function declarations that differ only in the return type, -the exception specification~(\ref{except.spec}), or both -cannot be overloaded. -\item -\indextext{\idxcode{static}!overloading and}% -Member function declarations with the same name and the same -parameter-type-list~(\ref{dcl.fct}) 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 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. -\begin{example} -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} -\end{example} - -\item Member function declarations with the same name and the same -parameter-type-list~(\ref{dcl.fct}) as well as member function template -declarations with the same name, the same 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}). \begin{example} - -\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{example} - -\end{itemize} - -\pnum -\indextext{equivalent parameter declarations}% -\indextext{equivalent parameter declarations!overloading and}% -\begin{note} -As specified in~\ref{dcl.fct}, -function declarations that have equivalent parameter declarations declare -the same function and therefore cannot -be overloaded: - -\begin{itemize} -\item -\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{example} -\begin{codeblock} -typedef int Int; - -void f(int i); -void f(Int i); // OK: redeclaration of \tcode{f(int)} -void f(int i) { @\commentellip@ } -void f(Int i) { @\commentellip@ } // error: redefinition of \tcode{f(int)} -\end{codeblock} -\end{example} - -\indextext{\idxcode{enum}!overloading and}% -Enumerations, on the other hand, are distinct types and can be used to -distinguish -overloaded function declarations. -\begin{example} -\begin{codeblock} -enum E { a }; - -void f(int i) { @\commentellip@ } -void f(E i) { @\commentellip@ } -\end{codeblock} -\end{example} - -\item -\indextext{overloading!array versus pointer}% -\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{example} - -\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} -\end{example} - -\item -\indextext{overloading!function versus pointer}% -\indextext{function!overloading and pointer versus}% -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{example} - -\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} -\end{example} - -\item -\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{example} -\begin{codeblock} -typedef const int cInt; - -int f (int); -int f (const int); // redeclaration of \tcode{f(int)} -int f (int) { @\commentellip@ } // definition of \tcode{f(int)} -int f (cInt) { @\commentellip@ } // error: redefinition of \tcode{f(int)} -\end{codeblock} -\end{example} - -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}, -``pointer to -\tcode{T}'', -``pointer to -\tcode{const} -\tcode{T}'', -and -``pointer to -\tcode{volatile} -\tcode{T}'' -are considered distinct parameter types, as are -``reference to -\tcode{T}'', -``reference to -\tcode{const} -\tcode{T}'', -and -``reference to -\tcode{volatile} -\tcode{T}''. -\item -\indextext{default initializers!overloading and}% -Two parameter declarations that differ only in their default arguments -are equivalent. -\begin{example} -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{example} -\end{itemize} -\end{note} - -\rSec1[over.dcl]{Declaration matching}% -\indextext{overloading!declaration matching}% -\indextext{scope!overloading and}% -\indextext{base class!overloading and} - -\pnum -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{example} - -\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} -\end{example} - -\pnum -A locally declared function is not in the same scope as a function in -a containing scope. -\begin{example} - -\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} -\end{example} - -\pnum -\indextext{access control!overloading and}% -\indextext{overloading!access control and}% -Different versions of an overloaded member function can be given different -access rules. -\begin{example} - -\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} -\end{example} - -\rSec1[over.match]{Overload resolution}% -\indextext{overloading!resolution|(}% -\indextext{resolution|see{overloading, resolution}}% -\indextext{ambiguity!overloaded function} - -\pnum -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. -\begin{note} -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. -\end{note} - -\pnum -\indextext{overloading!resolution!contexts}% -Overload resolution selects the function to call in seven distinct -contexts within the language: - -\begin{itemize} -\item -invocation of a function named in the function call syntax~(\ref{over.call.func}); -\item -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}); -\item -invocation of the operator referenced in an expression~(\ref{over.match.oper}); -\item -invocation of a constructor for default- or direct-initialization~(\ref{dcl.init}) -of a class object~(\ref{over.match.ctor}); -\item -invocation of a user-defined conversion for -copy-initialization~(\ref{dcl.init}) of a class object~(\ref{over.match.copy}); -\item -invocation of a conversion function for initialization of an object of a -non-class type from an expression of class type~(\ref{over.match.conv}); and -\item -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} -\item -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}). -\item -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} - -\pnum -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|(} - -\pnum -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. - -\pnum -\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. - -\pnum -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. - -\pnum -For non-static member functions, the type of the implicit object -parameter is - -\begin{itemize} -\item ``lvalue reference to \cv{}~\tcode{X}'' for functions declared -without a \grammarterm{ref-qualifier} or with the -\tcode{\&} \grammarterm{ref-qualifier} -\item ``rvalue reference to \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 -\cv{} -is the cv-qualification on the -member function declaration. -\begin{example} -For a -\tcode{const} -member -function of class -\tcode{X}, -the extra parameter is assumed to have type -``reference to -\tcode{const X}''. -\end{example} -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). -\begin{note} -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}). -\end{note} - -\pnum -\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 -no user-defined conversions can be applied to achieve a type -match with it. -\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} -\item -even if the implicit object parameter is not -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. -\begin{note} The fact that such an argument is an rvalue does not -affect the ranking of implicit conversion sequences~(\ref{over.ics.rank}). -\end{note} -\end{itemize} - -\pnum -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{example} - -\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} -\end{example} - -\pnum -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. - -\pnum -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|(} - -\pnum -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}. - -\pnum -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. \begin{note} The resolution of the address of an -overload set in other contexts is described in \ref{over.over}. \end{note} - -\rSec4[over.call.func]{Call to named function} - -\pnum -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. - -\pnum -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 ``\cv{}~\tcode{T}'' -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}). - -\pnum -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} - -\pnum -If the -\grammarterm{primary-expression} -\tcode{E} -in the function call syntax evaluates -to a class object of type ``\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()}. - -\pnum -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 noexcept-specifier\opt attribute-specifier-seq\opt{} \terminal{;} -\end{ncsimplebnf} - -where -\grammarterm{cv-qualifier} -is the same cv-qualification as, or a greater cv-qualification than, -\cv{}, -and where -\grammarterm{conversion-type-id} -denotes the type ``pointer to function -of ($\tcode{P}_1, \dotsc, \tcode{P}_n$) returning \tcode{R}'', -or the type ``reference to pointer to function -of ($\tcode{P}_1, \dotsc, \tcode{P}_n$) returning \tcode{R}'', -or the type -``reference to function of ($\tcode{P}_1, \dotsc, \tcode{P}_n$) -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, P$_1$ a$_1$, $\dotsc$, P$_n$ a$_n$)} \terminal{\{ return F (a$_1$, $\dotsc$, a$_n$); \}} -\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.}. - -\pnum -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. - -\pnum -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)}. -\begin{note} -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. -\end{note} -\begin{example} - -\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} -\end{example}% -\indextext{overloading!resolution!function call syntax|)} - -\rSec3[over.match.oper]{Operators in expressions}% -\indextext{overloading!resolution!operators} - -\pnum -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}. -\begin{note} -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}). -\end{note} -\begin{example} - -\begin{codeblock} -struct String { - String (const String&); - String (const char*); - operator const char* (); -}; -String operator + (const String&, const String&); - -void f() { - 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} -\end{example} - -\pnum -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). -However, the operands are sequenced in the order prescribed -for the built-in operator (Clause~\ref{expr}). - -\begin{floattable}{Relationship between operator and function call notation}{tab:over.rel.op.func} -{l|m|m|m} -\topline -\hdstyle{Subclause} & \hdstyle{Expression} & \hdstyle{As member function} & \hdstyle{As non-member function} \\ \capsep -\ref{over.unary} & \tcode{@a} & \tcode{(a).operator@ (\,)} & \tcode{operator@(a)} \\ -\ref{over.binary} & \tcode{a@b} & \tcode{(a).operator@ (b)} & \tcode{operator@(a, b)} \\ -\ref{over.ass} & \tcode{a=b} & \tcode{(a).operator= (b)} & \\ -\ref{over.sub} & \tcode{a[b]} & \tcode{(a).operator[](b)} & \\ -\ref{over.ref} & \tcode{a->} & \tcode{(a).operator->(\,)} & \\ -\ref{over.inc} & \tcode{a@} & \tcode{(a).operator@ (0)} & \tcode{operator@(a, 0)} \\ -\end{floattable} - -\pnum -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} -\item -If -\tcode{T1} -is a complete class type or a class currently being defined, the set of member candidates is the -result of the qualified lookup of -\tcode{T1::operator@}~(\ref{over.call.func}); otherwise, the set of member -candidates is empty. -\item -The set of non-member candidates is the result of the unqualified lookup of -\tcode{operator@} -in the context of -the expression according to the usual rules for name -lookup in unqualified function calls~(\ref{basic.lookup.argdep}) except -that all member functions are ignored. -However, if no operand has a class type, only those non-member -functions in the lookup set that have a first parameter of type -\tcode{T1} -or ``reference to \cv{}~\tcode{T1}'', -when -\tcode{T1} -is an enumeration type, -or (if there is a right operand) a second parameter of type -\tcode{T2} -or ``reference to \cv{}~\tcode{T2}'', -when -\tcode{T2} -is an enumeration type, -are candidate functions. -\item -For the operator -\tcode{,}, -the unary operator -\tcode{\&}, -or the operator -\tcode{->}, -the built-in candidates set is empty. -For all other operators, the built-in candidates include all -of the candidate operator functions defined in~\ref{over.built} that, -compared to the given operator, - -\begin{itemize} -\item -have the same operator name, and -\item -accept the same number of operands, and -\item -accept operand types to which the given operand or -operands can be converted according to \ref{over.best.ics}, and -\item -do not have the same parameter-type-list as any non-member candidate -that is not a function template specialization. -\end{itemize} -\end{itemize} - -\pnum -For the built-in assignment operators, conversions of the left -operand are restricted as follows: - -\begin{itemize} -\item -no temporaries are introduced to hold the left operand, and -\item -no user-defined conversions are applied to the left operand to achieve -a type match with the left-most parameter of a built-in candidate. -\end{itemize} - -\pnum -For all other operators, no such restrictions apply. - -\pnum -The set of candidate functions for overload resolution is the -union of the member candidates, the non-member candidates, and -the built-in candidates. -The argument list contains all of the -operands of the operator. -The best function from the set of candidate functions is selected -according to~\ref{over.match.viable} -and~\ref{over.match.best}.\footnote{If the set of candidate functions is empty, -overload resolution is unsuccessful.} -\begin{example} - -\begin{codeblock} -struct A { - operator int(); -}; -A operator+(const A&, const A&); -void m() { - A a, b; - a + b; // \tcode{operator+(a, b)} chosen over \tcode{int(a) + int(b)} -} -\end{codeblock} -\end{example} - -% USA _136/_28 L6899 USA core-756/734/682 over.match.oper -\pnum -If a built-in candidate is selected by overload resolution, the -operands of class type are converted to the types of the corresponding parameters -of the selected operation function, except that the second standard conversion -sequence of a user-defined conversion sequence~(\ref{over.ics.user}) is not applied. -Then the operator is treated as the corresponding -built-in operator and interpreted according to Clause~\ref{expr}. -\begin{example} -\begin{codeblock} -struct X { - operator double(); -}; - -struct Y { - operator int*(); -}; - -int *a = Y() + 100.0; // error: pointer arithmetic requires integral operand -int *b = Y() + X(); // error: pointer arithmetic requires integral operand -\end{codeblock} -\end{example} - -\pnum -The second operand of operator -\tcode{->} -is ignored in selecting an -\tcode{operator->} -function, and is not an argument when the -\tcode{operator->} -function is called. -When -\tcode{operator->} -returns, the operator -\tcode{->} -is applied to the value returned, with the original second -operand.\footnote{If the value returned by the -\tcode{operator->} -function has class type, this may result in selecting and calling another -\tcode{operator->} -function. -The process repeats until an -\tcode{operator->} -function returns a value of non-class type.} - -\pnum -If the operator is the operator -\tcode{,}, -the unary operator -\tcode{\&}, -or the operator -\tcode{->}, -and there are no viable functions, then the operator is -assumed to be the built-in operator and interpreted according to -Clause~\ref{expr}. - -\pnum -\begin{note} -The lookup rules for operators in expressions are different than -the lookup -rules for operator function names in a function call, as shown in the following -example: - -\begin{codeblock} -struct A { }; -void operator + (A, A); - -struct B { - void operator + (B); - void f (); -}; - -A a; - -void B::f() { - operator+ (a,a); // error: global operator hidden by member - a + a; // OK: calls global \tcode{operator+} -} -\end{codeblock} -\end{note} - -\rSec3[over.match.ctor]{Initialization by constructor}% -\indextext{overloading!resolution!initialization} - -\pnum -When objects of class type are direct-initialized~(\ref{dcl.init}), -copy-initialized from an expression of the same or a -derived class type~(\ref{dcl.init}), -or default-initialized~(\ref{dcl.init}), -overload resolution selects the constructor. -For direct-initialization or default-initialization -that is not in the context of copy-initialization, the -candidate functions are -all the constructors of the class of the object being -initialized. -For copy-initialization, the candidate functions are all -the converting constructors~(\ref{class.conv.ctor}) of that -class. -The argument list is the -\grammarterm{expression-list} or \grammarterm{assignment-expression} -of the \grammarterm{initializer}. - -\rSec3[over.match.copy]{Copy-initialization of class by user-defined conversion}% -\indextext{overloading!resolution!initialization} - -\pnum -Under the conditions specified in~\ref{dcl.init}, as -part of a copy-initialization of an object of class type, a user-defined -conversion can be invoked to convert an initializer expression to the -type of the object being initialized. -Overload resolution is used -to select the user-defined conversion to be invoked. -\begin{note} The conversion performed for indirect binding to a reference to a possibly -cv-qualified class type is determined in terms of a corresponding non-reference -copy-initialization. \end{note} -Assuming that -``\cvqual{cv1} \tcode{T}'' is the type of the object being initialized, with -\tcode{T} -a class type, -the candidate functions are selected as follows: - -\begin{itemize} -\item -The converting constructors~(\ref{class.conv.ctor}) of -\tcode{T} -are candidate functions. -\item -When the type of the initializer expression is a class type -``\cv{}~\tcode{S}'', -the non-explicit conversion functions of -\tcode{S} -and its base classes are considered. -When initializing a temporary to be bound to the first parameter of a -constructor -where the parameter is of type -``reference to possibly \cv-qualified \tcode{T}'' -and the constructor is -called with a single argument in the context of -direct-initialization of an object of type ``\cvqual{cv2} \tcode{T}'', explicit -conversion functions are also considered. -Those that are not hidden within -\tcode{S} -and yield a type whose cv-unqualified version is the same type as -\tcode{T} -or is a derived class thereof -are candidate functions. -Conversion functions that return ``reference to -\tcode{X}'' -return -lvalues or xvalues, depending on the type of reference, of type -\tcode{X} -and are therefore considered to yield -\tcode{X} -for this -process of selecting candidate functions. -\end{itemize} - -\pnum -In both cases, the argument list has one argument, which is the initializer -expression. -\begin{note} -This argument will be compared against -the first parameter of the constructors and against the implicit -object parameter of the conversion functions. -\end{note} - -\rSec3[over.match.conv]{Initialization by conversion function}% -\indextext{overloading!resolution!initialization} - -\pnum -Under the conditions specified in~\ref{dcl.init}, as -part of an initialization of an object of non-class type, -a conversion function can be invoked to convert an initializer -expression of class type to the type of the object -being initialized. -Overload resolution is used to select the -conversion function to be invoked. -Assuming that ``\cvqual{cv1} \tcode{T}'' is the -type of the object being initialized, and ``\cv{}~\tcode{S}'' is the type -of the initializer expression, with -\tcode{S} -a class type, -the candidate functions are selected as follows: - -\begin{itemize} -\item -The conversion functions of -\tcode{S} -and its base classes are considered. -Those non-explicit conversion functions that are not hidden -within -\tcode{S} -and yield type -\tcode{T} -or a type that can be converted to type -\tcode{T} -via a standard conversion sequence~(\ref{over.ics.scs}) -are candidate functions. -For direct-initialization, those explicit conversion functions that are not -hidden within \tcode{S} and yield type \tcode{T} or a type that can be converted -to type \tcode{T} with a qualification conversion~(\ref{conv.qual}) are also -candidate functions. -Conversion functions that return a cv-qualified type -are considered to yield the cv-unqualified version of that type -for this process of selecting candidate functions. -Conversion functions that return ``reference to -\cvqual{cv2} -\tcode{X}'' -return -lvalues or xvalues, depending on the type of reference, of type -``\cvqual{cv2} -\tcode{X}'' -and are therefore considered to yield -\tcode{X} -for this -process of selecting candidate functions. -\end{itemize} - -\pnum -The argument list has one argument, which is the initializer expression. -\begin{note} -This argument will be compared against -the implicit object parameter of the conversion functions. -\end{note} - -\rSec3[over.match.ref]{Initialization by conversion function for direct reference binding}% -\indextext{overloading!resolution!initialization} - -\pnum -Under the conditions specified in~\ref{dcl.init.ref}, a reference can be bound directly -to a glvalue or class prvalue that is the result of applying a conversion -function to an initializer expression. -Overload resolution is used to select the -conversion function to be invoked. -Assuming that ``reference to \cvqual{cv1} \tcode{T}'' is the -type of the reference being initialized, and -``\cv{}~\tcode{S}'' is the type -of the initializer expression, with -\tcode{S} -a class type, -the candidate functions are selected as follows: -\begin{itemize} -\item -The conversion functions of -\tcode{S} -and its base classes are considered. -Those non-explicit conversion functions that are not hidden within -\tcode{S} -and yield type ``lvalue reference to \cvqual{cv2} \tcode{T2}'' -(when initializing an lvalue reference or an rvalue reference to function) or -``\cvqual{cv2} \tcode{T2}'' -or ``rvalue reference to \cvqual{cv2} \tcode{T2}'' (when initializing an -rvalue reference or an lvalue reference to function), -where ``\cvqual{cv1} \tcode{T}'' is reference-compatible~(\ref{dcl.init.ref}) -with ``\cvqual{cv2} \tcode{T2}'', -are candidate functions. For direct-initialization, those explicit -conversion functions that are not hidden within \tcode{S} and yield -type ``lvalue reference to \cvqual{cv2} \tcode{T2}'' or ``\cvqual{cv2} -\tcode{T2}'' or ``rvalue reference to \cvqual{cv2} \tcode{T2}'', -respectively, where \tcode{T2} is the same type as \tcode{T} or can be -converted to type \tcode{T} with a qualification -conversion~(\ref{conv.qual}), are also candidate functions. - -\end{itemize} - -\pnum -The argument list has one argument, which is the initializer expression. -\begin{note} -This argument will be compared against -the implicit object parameter of the conversion functions. -\end{note} - -\rSec3[over.match.list]{Initialization by list-initialization}% -\indextext{overloading!resolution!initialization} - -\pnum -When objects of non-aggregate class type \tcode{T} are -list-initialized such that \ref{dcl.init.list} specifies that overload resolution -is performed according to the rules in this section, overload resolution selects the -constructor in two phases: - -\begin{itemize} -\item -Initially, the candidate functions are the initializer-list constructors~(\ref{dcl.init.list}) -of the class \tcode{T} and -the argument list consists of the initializer list as a single argument. - -\item -If no viable initializer-list constructor is found, overload resolution is -performed again, where the candidate functions are all the constructors of -the class \tcode{T} and -the argument list consists of the elements of the initializer list. -\end{itemize} - -If the initializer list has no elements and \tcode{T} has a default constructor, -the first phase is omitted. -In copy-list-initialization, if an \tcode{explicit} constructor is -chosen, the initialization is ill-formed. \begin{note} -This differs from other situations (\ref{over.match.ctor},~\ref{over.match.copy}), -where only converting constructors are considered for copy-initialization. -This restriction only -applies if this initialization is part of the final result of overload -resolution. \end{note} - -\rSec3[over.match.class.deduct]{Class template argument deduction}% -\indextext{deduction!class template arguments}% - -\pnum -A set of functions and function templates is formed comprising: - -\begin{itemize} -\item -For each constructor -of the primary class template -designated by the \grammarterm{template-name}, -if the template is defined, -a function template with the following properties: -\begin{itemize} -\item -The template parameters are the template parameters of the class template -followed -by the template parameters (including default template arguments) of the constructor, -if any. -\item -The types of the function parameters are those of the constructor. -\item -The return type is the class template specialization -designated by the \grammarterm{template-name} -and template arguments -corresponding to the template parameters -obtained from the class template. -\end{itemize} - -\item -If the primary class template \tcode{C} -is not defined or does not declare any constructors, -an additional function template derived as above -from a hypothetical constructor \tcode{C()}. - -\item -An additional function template derived as above -from a hypothetical constructor \tcode{C(C)}, -called the \defn{copy deduction candidate}. - -\item -For each \grammarterm{deduction-guide}, -a function or function template -with the following properties: - -\begin{itemize} -\item -The template parameters, if any, -and function parameters -are those of the \grammarterm{deduction-guide}. -\item -The return type -is the \grammarterm{simple-template-id} -of the \grammarterm{deduction-guide}. -\end{itemize} -\end{itemize} - -\pnum -Initialization and overload resolution are performed as described -in \ref{dcl.init} and \ref{over.match.ctor}, \ref{over.match.copy}, -or \ref{over.match.list} (as appropriate for the type of initialization -performed) for an object of a hypothetical class type, where -the selected functions and function templates are considered to be the -constructors of that class type for the purpose of forming an overload -set, and the initializer is provided by the context in which class -template argument deduction was performed. Each such notional constructor -is considered to be explicit if the function or function template was -generated from a constructor or \grammarterm{deduction-guide} that was -declared \tcode{explicit}. -All such notional constructors are considered to be -public members of the hypothetical class type. - -\pnum -\begin{example} -\begin{codeblock} -template struct A { - explicit A(const T&, ...) noexcept; // \#1 - A(T&&, ...); // \#2 -}; - -int i; -A a1 = { i, i }; // error: explicit constructor \#1 selected in copy-list-initialization during deduction, - // cannot deduce from non-forwarding rvalue reference in \#2 - -A a2{i, i}; // OK, \#1 deduces to \tcode{A} and also initializes -A a3{0, i}; // OK, \#2 deduces to \tcode{A} and also initializes -A a4 = {0, i}; // OK, \#2 deduces to \tcode{A} and also initializes - -template A(const T&, const T&) -> A; // \#3 -template explicit A(T&&, T&&) -> A; // \#4 - -A a5 = {0, 1}; // error: explicit deduction guide \#4 selected in copy-list-initialization during deduction -A a6{0,1}; // OK, \#4 deduces to \tcode{A} and \#2 initializes -A a7 = {0, i}; // error: \#3 deduces to \tcode{A}, \#1 and \#2 declare same constructor -A a8{0,i}; // error: \#3 deduces to \tcode{A}, \#1 and \#2 declare same constructor - -template struct B { - template using TA = T; - template B(U, TA); -}; - -B b{(int*)0, (char*)0}; // OK, deduces \tcode{B} -\end{codeblock} -\end{example}% -\indextext{overloading!argument lists|)}% -\indextext{overloading!candidate functions|)} - -\rSec2[over.match.viable]{Viable functions}% -\indextext{overloading!resolution!viable functions|(} - -\pnum -From the set of candidate functions constructed for a given -context~(\ref{over.match.funcs}), a set of viable functions is -chosen, from which the best function will be selected by -comparing argument conversion sequences for the best fit~(\ref{over.match.best}). -The selection of viable functions considers -relationships between arguments and function parameters other -than the ranking of conversion sequences. - -\pnum -\indextext{ellipsis!overload resolution and}% -\indextext{default argument!overload resolution and}% -First, to be a viable function, a candidate function shall have -enough parameters to agree in number with the arguments in the -list. - -\begin{itemize} -\item -If there are -\textit{m} -arguments in the list, all candidate -functions having exactly -\textit{m} -parameters are viable. -\item -A candidate function having fewer than -\textit{m} -parameters is -viable only if it has an ellipsis in its parameter list~(\ref{dcl.fct}). -For the purposes of overload resolution, -any argument for which there is no corresponding parameter is -considered to ``match the ellipsis''~(\ref{over.ics.ellipsis}) . -\item -A candidate function having more than -\textit{m} -parameters is viable -only if the -\textit{(m+1)}-st -parameter has a default -argument~(\ref{dcl.fct.default}).\footnote{According to~\ref{dcl.fct.default}, -parameters following the -\textit{(m+1)}-st -parameter must also have default arguments.} -For the purposes of overload -resolution, the parameter list is truncated on the right, so -that there are exactly -\textit{m} -parameters. -\end{itemize} - -\pnum -Second, for -\tcode{F} -to be a viable function, there shall exist for each -argument an -\term{implicit conversion sequence}~(\ref{over.best.ics}) that -converts that argument to the corresponding parameter of -\tcode{F}. -If the parameter has reference type, the implicit conversion sequence -includes the operation of binding the reference, and the fact that -an lvalue reference to non-\tcode{const} cannot be bound to an rvalue -and that an rvalue reference cannot be bound to an lvalue -can affect -the viability of the function (see~\ref{over.ics.ref}). - -\rSec2[over.match.best]{Best viable function}% -\indextext{overloading!resolution!best viable function|(} - -\pnum -\indextext{conversion!overload resolution and}% -Define ICS\textit{i}(\tcode{F}) as follows: -\begin{itemize} -\item -If -\tcode{F} -is a static member function, ICS\textit{1}(\tcode{F}) is defined such that -ICS\textit{1}(\tcode{F}) is neither better nor worse than ICS\textit{1}(\tcode{G}) -for any function -\tcode{G}, -and, symmetrically, ICS\textit{1}(\tcode{G}) is neither better nor worse than -ICS\textit{1}(\tcode{F});\footnote{If a function is a static member function, this -definition means that the first argument, the implied object argument, -has no effect in the determination of whether the function is better -or worse than any other function.} -otherwise, -\item -let ICS\textit{i}(\tcode{F}) denote the implicit conversion sequence that converts -the \textit{i}-th argument in the list to the type of the -\textit{i}-th -parameter -of viable function -\tcode{F}. -\ref{over.best.ics} defines the implicit conversion sequences and \ref{over.ics.rank} -defines what it means for one implicit conversion sequence to be -a better conversion sequence or worse conversion sequence than -another. -\end{itemize} - -Given these definitions, a viable function -\tcode{F1} -is defined -to be a -\term{better} -function than another viable function -\tcode{F2} -if -for all arguments -\textit{i}, -ICS\textit{i}(\tcode{F1}) is not a worse conversion -sequence than ICS\textit{i}(\tcode{F2}), and then -\begin{itemize} -\item -for some argument -\textit{j}, -ICS\textit{j}(\tcode{F1}) is a better conversion -sequence than ICS\textit{j}(\tcode{F2}), or, if not that, - -\item -the context is an initialization by user-defined conversion -(see~\ref{dcl.init}, -\ref{over.match.conv}, and~\ref{over.match.ref}) -and the standard conversion sequence from the return type of -\tcode{F1} -to the destination type (i.e., the type of the entity being initialized) -is a better conversion sequence than the standard conversion sequence -from the return type of -\tcode{F2} -to the destination type -\begin{example} -\begin{codeblock} -struct A { - A(); - operator int(); - operator double(); -} a; -int i = a; // \tcode{a.operator int()} followed by no conversion is better than - // \tcode{a.operator double()} followed by a conversion to \tcode{int} -float x = a; // ambiguous: both possibilities require conversions, - // and neither is better than the other -\end{codeblock} -\end{example} -or, if not that, - -\item the context is an initialization by conversion function for direct -reference binding (\ref{over.match.ref}) of a reference to function type, the -return type of \tcode{F1} is the same kind of reference (i.e. lvalue or rvalue) -as the reference being initialized, and the return type of \tcode{F2} is not -\begin{example} -\begin{codeblock} -template struct A { - operator T&(); // \#1 - operator T&&(); // \#2 -}; -typedef int Fn(); -A a; -Fn& lf = a; // calls \#1 -Fn&& rf = a; // calls \#2 -\end{codeblock} -\end{example} -or, if not that, - -\item -\tcode{F1} -is not a function template specialization and -\tcode{F2} -is a -function template -specialization, or, if not that, - -\item -\tcode{F1} -and -\tcode{F2} -are -function template specializations, -and the function template -for -\tcode{F1} -is more specialized than the template for -\tcode{F2} -according to the partial ordering rules described in~\ref{temp.func.order}, -or, if not that, - -\item -\tcode{F1} is generated from a -\grammarterm{deduction-guide}~(\ref{over.match.class.deduct}) -and \tcode{F2} is not, or, if not that, -\begin{example} -\begin{codeblock} -template struct A { - A(T, int*); // \#1 - A(A&, int*); // \#2 - enum { value }; -}; - -template A(T&&, int*) -> A; // \#3 - -A a{1, 0}; // uses \#1 to deduce \tcode{A} and initializes with \#1 -A b{a, 0}; // uses \#3 (not \#2) to deduce \tcode{A\&>} and initializes with \#1 -\end{codeblock} -\end{example} -\end{itemize} - -\pnum -If there is exactly one viable function that is a better function -than all other viable functions, then it is the one selected by -overload resolution; otherwise the call is ill-formed.\footnote{The algorithm -for selecting the best viable function is linear in the number -of viable -functions. -Run a simple tournament to find a function -\tcode{W} -that is not -worse than any -opponent it faced. -Although another function -\tcode{F} -that -\tcode{W} -did not face -might be at least as good as -\tcode{W}, -\tcode{F} -cannot be the best function because at some point in the -tournament -\tcode{F} -encountered another function -\tcode{G} -such that -\tcode{F} -was not better than -\tcode{G}. -Hence, -\tcode{W} -is either -the best function or there is no best function. -So, make a second pass over -the viable -functions to verify that -\tcode{W} -is better than all other functions.} -\begin{example} -\begin{codeblock} -void Fcn(const int*, short); -void Fcn(int*, int); - -int i; -short s = 0; - -void f() { - Fcn(&i, s); // is ambiguous because \tcode{\&i} $\to$ \tcode{int*} is better than \tcode{\&i} $\to$ \tcode{const int*} - // but \tcode{s} $\to$ \tcode{short} is also better than \tcode{s} $\to$ \tcode{int} - - Fcn(&i, 1L); // calls \tcode{Fcn(int*, int)}, because \tcode{\&i} $\to$ \tcode{int*} is better than \tcode{\&i} $\to$ \tcode{const int*} - // and \tcode{1L} $\to$ \tcode{short} and \tcode{1L} $\to$ \tcode{int} are indistinguishable - - Fcn(&i, 'c'); // calls \tcode{Fcn(int*, int)}, because \tcode{\&i} $\to$ \tcode{int*} is better than \tcode{\&i} $\to$ \tcode{const int*} - // and \tcode{c} $\to$ \tcode{int} is better than \tcode{c} $\to$ \tcode{short} -} -\end{codeblock} -\end{example} - -\pnum -If the best viable function resolves to a function for -which multiple declarations were found, and if at least -two of these declarations --- or the declarations they -refer to in the case of -\grammarterm{using-declaration}{s} ---- specify a default argument that made the function -viable, the program is ill-formed. -\begin{example} -\begin{codeblock} -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 -} -\end{codeblock} -\end{example} - -\rSec3[over.best.ics]{Implicit conversion sequences}% -\indextext{overloading!resolution!implicit conversions and|(} - -\pnum -An -\term{implicit conversion sequence} -\indextext{sequence!implicit conversion}% -is a sequence of conversions used -to convert an argument in a function call to the type of the -corresponding parameter of the function being called. -The -sequence of conversions is an implicit conversion as defined in -Clause~\ref{conv}, which means it is governed by the rules for -initialization of an object or reference by a single -expression~(\ref{dcl.init}, \ref{dcl.init.ref}). - -\pnum -Implicit conversion sequences are concerned only with the type, -cv-qualification, and value category of the argument and how these -are converted to match the corresponding properties of the -parameter. -Other properties, such as the lifetime, storage class, -alignment, accessibility of the argument, whether the argument is a bit-field, -and whether a function is deleted~(\ref{dcl.fct.def.delete}), are ignored. -So, although an implicit -conversion sequence can be defined for a given argument-parameter -pair, the conversion from the argument to the parameter might still -be ill-formed in the final analysis. - -\pnum -A -well-formed implicit conversion -sequence is one of the following forms: - -\begin{itemize} -\item -a -\term{standard conversion sequence}~(\ref{over.ics.scs}), -\item -a -\grammarterm{user-defined conversion sequence}~(\ref{over.ics.user}), or -\item -an -\term{ellipsis conversion sequence}~(\ref{over.ics.ellipsis}). -\end{itemize} - -\pnum -However, if the target is -\begin{itemize} -\item the first parameter of a constructor or -\item the implicit object parameter of a user-defined conversion function -\end{itemize} -and the constructor or user-defined conversion function is a candidate by -\begin{itemize} -\item \ref{over.match.ctor}, when the argument is the temporary in the second -step of a class copy-initialization, -\item \ref{over.match.copy}, \ref{over.match.conv}, or \ref{over.match.ref} -(in all cases), or -\item the second phase of \ref{over.match.list} -when the initializer list has exactly one element that -is itself an initializer list, and -the target is the first parameter of a constructor of class \tcode{X}, and -the conversion is to \tcode{X} or reference to \cv{}~\tcode{X}, -\end{itemize} -user-defined conversion sequences are not considered. -\begin{note} -These rules prevent more than one user-defined conversion from being -applied during overload resolution, thereby avoiding infinite recursion. -\end{note} -\begin{example} -\begin{codeblock} - struct Y { Y(int); }; - struct A { operator int(); }; - Y y1 = A(); // error: \tcode{A::operator int()} is not a candidate - - struct X { }; - struct B { operator X(); }; - B b; - X x({b}); // error: \tcode{B::operator X()} is not a candidate -\end{codeblock} -\end{example} - -\pnum -For the case where the parameter type is a reference, see~\ref{over.ics.ref}. - -\pnum -When the parameter type is not a reference, the implicit conversion -sequence models a copy-initialization of the parameter from the argument -expression. -The implicit conversion sequence is the one required to convert the -argument expression to a prvalue of the type of -the parameter. -\begin{note} -When the parameter has a class type, this is a conceptual conversion -defined for the purposes of Clause~\ref{over}; the actual initialization is -defined in terms of constructors and is not a conversion. -\end{note} -Any difference in top-level cv-qualification is -subsumed by the initialization itself and does not constitute a conversion. -\begin{example} -A parameter of type -\tcode{A} -can be initialized from an argument of type -\tcode{const A}. -The implicit conversion sequence for that case is the identity sequence; it -contains no ``conversion'' from -\tcode{const A} -to -\tcode{A}. -\end{example} -When the parameter has a class type and the argument expression has the -same type, the implicit conversion sequence is an identity conversion. -When the parameter has a class type and the argument expression has a -derived class type, the implicit conversion sequence is a -derived-to-base -\indextext{conversion!derived-to-base}% -Conversion from the derived class to the base class. -\begin{note} -There is no such standard conversion; this derived-to-base Conversion exists -only in the description of implicit conversion sequences. -\end{note} -A derived-to-base Conversion has Conversion rank~(\ref{over.ics.scs}). - -\pnum -In all contexts, when converting to the implicit object parameter -or when converting to the left operand of an assignment operation -only standard conversion sequences are allowed. - -\pnum -If no conversions are required to match an argument to a -parameter type, the implicit conversion sequence is the standard -conversion sequence consisting of the identity conversion~(\ref{over.ics.scs}). - -\pnum -If no sequence of conversions can be found to convert an argument -to a parameter type, an implicit conversion sequence cannot be formed. - -\pnum -If several different sequences of conversions exist that each -convert the argument to the parameter type, the implicit -conversion sequence associated with the parameter is defined to be -the unique conversion sequence designated the -\term{ambiguous conversion sequence}. -\indextext{sequence!ambiguous conversion}% -For the purpose of ranking implicit conversion sequences as described -in~\ref{over.ics.rank}, the ambiguous conversion sequence is treated -as a user-defined conversion sequence that is indistinguishable from any -other user-defined conversion sequence. -\begin{note} -This rule prevents a function from becoming non-viable because of an ambiguous -conversion sequence for one of its parameters. -\begin{example} -\begin{codeblock} -class B; -class A { A (B&);}; -class B { operator A (); }; -class C { C (B&); }; -void f(A) { } -void f(C) { } -B b; -f(b); // ill-formed: ambiguous because there is a conversion \tcode{b} $\to$ \tcode{C} (via constructor) - // and an (ambiguous) conversion \tcode{b} $\to$ \tcode{A} (via constructor or conversion function) -void f(B) { } -f(b); // OK, unambiguous -\end{codeblock} -\end{example} -\end{note} -If a function that uses the ambiguous conversion sequence is selected -as the best viable function, the call will be ill-formed because the conversion -of one of the arguments in the call is ambiguous. - -\pnum -The three forms of implicit conversion sequences mentioned above -are defined in the following subclauses. - -\rSec4[over.ics.scs]{Standard conversion sequences} - -\pnum -Table~\ref{tab:over.conversions} -summarizes the conversions defined in Clause~\ref{conv} and -partitions them into four disjoint categories: Lvalue Transformation, -Qualification Adjustment, Promotion, and Conversion. -\begin{note} -These categories are orthogonal with respect to value category, -cv-qualification, and data representation: the Lvalue Transformations -do not change the cv-qualification or data -representation of the type; the Qualification Adjustments do not -change the value category or data representation of the type; and -the Promotions and Conversions do not change the -value category or cv-qualification of the type. -\end{note} - -\pnum -\begin{note} -As described in Clause~\ref{conv}, -a standard conversion sequence is either the Identity conversion -by itself (that is, no conversion) or consists of one to three -conversions from the other -four categories. -If there are two or more conversions in the sequence, the -conversions are applied in the canonical order: -\textbf{Lvalue Transformation}, -\textbf{Promotion} -or -\textbf{Conversion}, -\textbf{Qualification Adjustment}. -\end{note} - -\pnum -\indextext{conversion rank}% -Each conversion in Table~\ref{tab:over.conversions} -also has an associated rank (Exact -Match, Promotion, or Conversion). -These are used -to rank standard conversion sequences~(\ref{over.ics.rank}). -The rank of a conversion sequence is determined by considering the -rank of each conversion in the sequence and the rank of any reference -binding~(\ref{over.ics.ref}). -If any of those has Conversion rank, the -sequence has Conversion rank; otherwise, if any of those has Promotion rank, -the sequence has Promotion rank; otherwise, the sequence has Exact -Match rank. - -\begin{floattable}{Conversions}{tab:over.conversions}{l|c|c|c} -\topline -\hdstyle{Conversion} & \hdstyle{Category} & \hdstyle{Rank} & \hdstyle{Subclause} \\ \capsep -No conversions required & Identity & & \\ \cline{1-2}\cline{4-4} -Lvalue-to-rvalue conversion & & & \ref{conv.lval} \\ \cline{1-1}\cline{4-4} -Array-to-pointer conversion & Lvalue Transformation & & \ref{conv.array} \\ \cline{1-1}\cline{4-4} -Function-to-pointer conversion & & \rb{Exact Match}& \ref{conv.func} \\ \cline{1-2}\cline{4-4} -Qualification conversions & & & \ref{conv.qual} \\ \cline{1-1}\cline{4-4} -Function pointer conversion & \rb{Qualification Adjustment} & & \ref{conv.fctptr} \\ \hline -Integral promotions & & & \ref{conv.prom} \\ \cline{1-1}\cline{4-4} -Floating-point promotion & \rb{Promotion} & \rb{Promotion} & \ref{conv.fpprom} \\ \hline -Integral conversions & & & \ref{conv.integral} \\ \cline{1-1}\cline{4-4} -Floating-point conversions & & & \ref{conv.double} \\ \cline{1-1}\cline{4-4} -Floating-integral conversions & & & \ref{conv.fpint} \\ \cline{1-1}\cline{4-4} -Pointer conversions & \rb{Conversion} & \rb{Conversion} & \ref{conv.ptr} \\ \cline{1-1}\cline{4-4} -Pointer to member conversions & & & \ref{conv.mem} \\ \cline{1-1}\cline{4-4} -Boolean conversions & & & \ref{conv.bool} \\ -\end{floattable} - -\rSec4[over.ics.user]{User-defined conversion sequences} - -\pnum -A user-defined conversion sequence consists of an initial -standard conversion sequence followed by a user-defined -conversion~(\ref{class.conv}) followed by a second standard -conversion sequence. -If the user-defined conversion is specified -by a constructor~(\ref{class.conv.ctor}), the initial standard -conversion sequence converts the source type to the type required -by the argument of the constructor. -If the user-defined -conversion is specified by a conversion function~(\ref{class.conv.fct}), the -initial standard conversion sequence -converts the source type to the implicit object parameter of the -conversion function. - -\pnum -The second standard conversion sequence converts the result of -the user-defined conversion to the target type for the sequence. -Since an implicit conversion sequence is an initialization, the -special rules for initialization by user-defined conversion apply -when selecting the best user-defined conversion for a -user-defined conversion sequence (see~\ref{over.match.best} and~\ref{over.best.ics}). - -\pnum -If the user-defined conversion is specified by a -specialization of a conversion function template, -the second standard conversion sequence shall have exact match rank. - -\pnum -A conversion of an expression of class type -to the same class type is given Exact Match rank, and -a conversion of an expression of class type -to a base class of that type is given Conversion rank, -in spite of the -fact that a constructor (i.e., a user-defined conversion -function) is called for those cases. - -\rSec4[over.ics.ellipsis]{Ellipsis conversion sequences} - -\pnum -\indextext{ellipsis!conversion sequence}% -An ellipsis conversion sequence occurs when an argument in a -function call is matched with the ellipsis parameter -specification of the function called (see~\ref{expr.call}). - -\rSec4[over.ics.ref]{Reference binding} - -\pnum -When a parameter of reference type binds directly~(\ref{dcl.init.ref}) to an -argument expression, the implicit conversion sequence is the identity conversion, -unless the argument expression has a type that is a derived class of the parameter -type, in which case the implicit conversion sequence is a derived-to-base -Conversion~(\ref{over.best.ics}). -\begin{example} - -\begin{codeblock} -struct A {}; -struct B : public A {} b; -int f(A&); -int f(B&); -int i = f(b); // calls \tcode{f(B\&)}, an exact match, rather than \tcode{f(A\&)}, a conversion -\end{codeblock} -\end{example} -If the parameter binds directly to the result of -applying a conversion function to the argument expression, the implicit -conversion sequence is a user-defined conversion sequence~(\ref{over.ics.user}), -with the second standard conversion sequence either an identity conversion or, -if the conversion function returns an entity of a type that is a derived class -of the parameter type, a derived-to-base Conversion. - -\pnum -When a parameter of reference type is not bound directly to an argument -expression, the conversion sequence is the one required to convert the argument -expression to the referenced type according to~\ref{over.best.ics}. -Conceptually, this conversion sequence corresponds to copy-initializing a -temporary of the referenced type with the argument expression. -Any difference -in top-level cv-qualification is subsumed by the initialization itself and -does not constitute a conversion. - -\pnum -Except for an implicit object parameter, for which see~\ref{over.match.funcs}, a -standard conversion sequence cannot be formed if it requires -binding an lvalue reference -other than a reference to a non-volatile \tcode{const} type -to an rvalue -or binding an rvalue reference to an lvalue other than a function lvalue. -\begin{note} -This means, for example, that a candidate function cannot be a viable -function if it has a non-\tcode{const} lvalue reference parameter (other than -the implicit object parameter) and the corresponding argument -would require a temporary to be created to initialize the lvalue -reference (see~\ref{dcl.init.ref}). -\end{note} - -\pnum -Other restrictions on binding a reference to a particular argument -that are not based on the types of the reference and the argument -do not affect the formation of a standard conversion -sequence, however. -\begin{example} -A function with an ``lvalue reference to \tcode{int}'' parameter can -be a viable candidate even if the corresponding argument is an -\tcode{int} -bit-field. -The formation of implicit conversion sequences -treats the -\tcode{int} -bit-field as an -\tcode{int} -lvalue and finds an exact -match with the parameter. -If the function is selected by overload -resolution, the call will nonetheless be ill-formed because of -the prohibition on binding a non-\tcode{const} lvalue reference to a bit-field~(\ref{dcl.init.ref}). -\end{example} - -\rSec4[over.ics.list]{List-initialization sequence} - -\pnum -When an argument is an initializer list~(\ref{dcl.init.list}), it is not an -expression and special rules apply for converting it to a parameter type. - -\pnum -If the parameter type is an aggregate class \tcode{X} and the initializer list has a -single element of type \cv{}~\tcode{U}, where \tcode{U} is \tcode{X} -or a class derived from \tcode{X}, the implicit conversion sequence is the one -required to convert the element to the parameter type. - -\pnum -Otherwise, if the parameter type is a character array% -\footnote{Since there are no parameters of array type, -this will only occur as the referenced type of a reference parameter.} -and the initializer list has a single element that is an appropriately-typed -string literal~(\ref{dcl.init.string}), the implicit conversion -sequence is the identity conversion. - -\pnum -Otherwise, if the parameter type is \tcode{std::initializer_list} -and all the elements -of the initializer list can be implicitly converted to \tcode{X}, the implicit -conversion sequence is the worst conversion necessary to convert an element of -the list to \tcode{X}, or if the initializer list has no elements, the identity -conversion. This conversion can be a user-defined conversion even in -the context of a call to an initializer-list constructor. \begin{example} -\begin{codeblock} -void f(std::initializer_list); -f( {} ); // OK: \tcode{f(initializer_list)} identity conversion -f( {1,2,3} ); // OK: \tcode{f(initializer_list)} identity conversion -f( {'a','b'} ); // OK: \tcode{f(initializer_list)} integral promotion -f( {1.0} ); // error: narrowing - -struct A { - A(std::initializer_list); // \#1 - A(std::initializer_list>); // \#2 - A(std::initializer_list); // \#3 -}; -A a{ 1.0,2.0 }; // OK, uses \#1 - -void g(A); -g({ "foo", "bar" }); // OK, uses \#3 - -typedef int IA[3]; -void h(const IA&); -h({ 1, 2, 3 }); // OK: identity conversion -\end{codeblock} -\end{example} - -\pnum -Otherwise, if the parameter type is ``array of \tcode{N} \tcode{X}'', -if there exists an implicit conversion sequence for each element of the array -from the corresponding element of the initializer list (or from \tcode{\{\}} -if there is no such element), the implicit conversion sequence is -the worst such implicit conversion sequence. - -\pnum -Otherwise, if the parameter is a non-aggregate class \tcode{X} and overload -resolution per~\ref{over.match.list} chooses a single best constructor \tcode{C} of -\tcode{X} to perform the initialization of an object of type \tcode{X} from the -argument initializer list: -\begin{itemize} -\item -If \tcode{C} is not an initializer-list constructor -and the initializer list has a single element of type \cv{}~\tcode{U}, -where \tcode{U} is \tcode{X} or a class derived from \tcode{X}, -the implicit conversion sequence has Exact Match rank if \tcode{U} is \tcode{X}, -or Conversion rank if \tcode{U} is derived from \tcode{X}. -\item -Otherwise, the implicit conversion sequence is a user-defined -conversion sequence with the second standard conversion sequence an -identity conversion. -\end{itemize} -If multiple constructors are viable but none is better than -the others, the implicit conversion sequence is the ambiguous conversion -sequence. User-defined conversions are allowed for conversion of the initializer -list elements to the constructor parameter types except as noted -in~\ref{over.best.ics}. -\begin{example} -\begin{codeblock} -struct A { - A(std::initializer_list); -}; -void f(A); -f( {'a', 'b'} ); // OK: \tcode{f(A(std::initializer_list))} user-defined conversion - -struct B { - B(int, double); -}; -void g(B); -g( {'a', 'b'} ); // OK: \tcode{g(B(int, double))} user-defined conversion -g( {1.0, 1.0} ); // error: narrowing - -void f(B); -f( {'a', 'b'} ); // error: ambiguous \tcode{f(A)} or \tcode{f(B)} - -struct C { - C(std::string); -}; -void h(C); -h({"foo"}); // OK: \tcode{h(C(std::string("foo")))} - -struct D { - D(A, C); -}; -void i(D); -i({ {1,2}, {"bar"} }); // OK: \tcode{i(D(A(std::initializer_list\{1,2\}), C(std::string("bar"))))} -\end{codeblock} -\end{example} - -\pnum -Otherwise, if the parameter has an aggregate type which can be initialized from -the initializer list according to the rules for aggregate -initialization~(\ref{dcl.init.aggr}), the implicit conversion sequence is a -user-defined conversion sequence with the second standard conversion -sequence an identity conversion. \begin{example} -\begin{codeblock} -struct A { - int m1; - double m2; -}; - -void f(A); -f( {'a', 'b'} ); // OK: \tcode{f(A(int,double))} user-defined conversion -f( {1.0} ); // error: narrowing -\end{codeblock} -\end{example} - -\pnum -Otherwise, if the parameter is a reference, see~\ref{over.ics.ref}. \begin{note} -The rules in this section will apply for initializing the underlying temporary -for the reference. \end{note} \begin{example} -\begin{codeblock} -struct A { - int m1; - double m2; -}; - -void f(const A&); -f( {'a', 'b'} ); // OK: \tcode{f(A(int,double))} user-defined conversion -f( {1.0} ); // error: narrowing - -void g(const double &); -g({1}); // same conversion as \tcode{int} to \tcode{double} -\end{codeblock} -\end{example} - -\pnum -Otherwise, if the parameter type is not a class: - -\begin{itemize} -\item if the initializer list has one element that is not itself an initializer list, -the implicit conversion sequence is the one required to convert the element to -the parameter type; \begin{example} -\begin{codeblock} -void f(int); -f( {'a'} ); // OK: same conversion as \tcode{char} to \tcode{int} -f( {1.0} ); // error: narrowing -\end{codeblock} -\end{example} - -\item if the initializer list has no elements, the implicit conversion sequence -is the identity conversion. \begin{example} -\begin{codeblock} -void f(int); -f( { } ); // OK: identity conversion -\end{codeblock} -\end{example} -\end{itemize} - -\pnum -In all cases other than those enumerated above, no conversion is possible. - -\rSec3[over.ics.rank]{Ranking implicit conversion sequences} - -\pnum -This subclause defines a partial ordering of implicit conversion -sequences based on the relationships -\term{better conversion sequence} -and -\term{better conversion}. -If an implicit conversion sequence S1 is -defined by these rules to be a better conversion sequence than -S2, then it is also the case that S2 is a -\term{worse conversion sequence} -than S1. -If conversion sequence S1 is neither better -than nor worse than conversion sequence S2, S1 and S2 are said to -be -\term{indistinguishable conversion sequences}. - -\pnum -When comparing the basic forms of implicit conversion sequences -(as defined in~\ref{over.best.ics}) - -\begin{itemize} -\item -a standard conversion sequence~(\ref{over.ics.scs}) is a better -conversion sequence than a user-defined conversion sequence -or an ellipsis conversion sequence, and -\item -a user-defined conversion sequence~(\ref{over.ics.user}) is a -better conversion sequence than an ellipsis conversion -sequence~(\ref{over.ics.ellipsis}). -\end{itemize} - -\pnum -Two implicit conversion sequences of the same form are -indistinguishable conversion sequences unless one of the -following rules applies: - -\begin{itemize} -\item -List-initialization sequence \tcode{L1} is a better conversion sequence than -list-initialization sequence \tcode{L2} if - -\begin{itemize} -\item -\tcode{L1} converts to \tcode{std::initializer_list} for some \tcode{X} and -\tcode{L2} does not, or, if not that, - -\item -\tcode{L1} converts to type ``array of \tcode{N1} \tcode{T}'', \tcode{L2} converts to -type ``array of \tcode{N2} \tcode{T}'', and \tcode{N1} is smaller than \tcode{N2}, -\end{itemize} -even if one of the other rules in this paragraph would otherwise apply. -\begin{example} -\begin{codeblock} - void f1(int); // \#1 - void f1(std::initializer_list); // \#2 - void g1() { f1({42}); } // chooses \#2 - - void f2(std::pair); // \#3 - void f2(std::initializer_list); // \#4 - void g2() { f2({"foo","bar"}); } // chooses \#4 -\end{codeblock} -\end{example} - -\item -Standard conversion sequence -\tcode{S1} -is a better conversion -sequence than standard conversion sequence -\tcode{S2} -if - -\begin{itemize} -\item -\indextext{subsequence rule!overloading}% -\tcode{S1} -is a proper subsequence of -\tcode{S2} -(comparing the conversion sequences in the canonical form defined -by~\ref{over.ics.scs}, excluding any Lvalue Transformation; -the identity conversion sequence is considered to be a -subsequence of any non-identity conversion sequence) -or, if not that, -\item -the rank of -\tcode{S1} -is better than the rank of -\tcode{S2}, -or -\tcode{S1} -and -\tcode{S2} -have the same rank and are distinguishable by the rules -in the paragraph below, -or, if not that, - -\item \tcode{S1} and \tcode{S2} are reference bindings~(\ref{dcl.init.ref}) and -neither refers to an implicit object parameter of a non-static member function -declared without a \grammarterm{ref-qualifier}, -and \tcode{S1} binds an rvalue reference to an -rvalue and \tcode{S2} binds an lvalue reference -\begin{example} -\begin{codeblock} -int i; -int f1(); -int&& f2(); -int g(const int&); -int g(const int&&); -int j = g(i); // calls \tcode{g(const int\&)} -int k = g(f1()); // calls \tcode{g(const int\&\&)} -int l = g(f2()); // calls \tcode{g(const int\&\&)} - -struct A { - A& operator<<(int); - void p() &; - void p() &&; -}; -A& operator<<(A&&, char); -A() << 1; // calls \tcode{A::operator<<(int)} -A() << 'c'; // calls \tcode{operator<<(A\&\&, char)} -A a; -a << 1; // calls \tcode{A::operator<<(int)} -a << 'c'; // calls \tcode{A::operator<<(int)} -A().p(); // calls \tcode{A::p()\&\&} -a.p(); // calls \tcode{A::p()\&} -\end{codeblock} -\end{example} -or, if not that, - -\item -\tcode{S1} and \tcode{S2} are reference bindings~(\ref{dcl.init.ref}) and -\tcode{S1} binds an lvalue reference to a function lvalue and \tcode{S2} binds -an rvalue reference to a function lvalue -\begin{example} -\begin{codeblock} -int f(void(&)()); // \#1 -int f(void(&&)()); // \#2 -void g(); -int i1 = f(g); // calls \#1 -\end{codeblock} -\end{example} -or, if not that, - -\item -\tcode{S1} -and -\tcode{S2} -differ only in their qualification conversion and yield similar types -\tcode{T1} -and -\tcode{T2}~(\ref{conv.qual}), respectively, and the cv-qualification signature of type -\tcode{T1} -is a proper subset of the cv-qualification signature of type -\tcode{T2} -\begin{example} -\begin{codeblock} -int f(const volatile int *); -int f(const int *); -int i; -int j = f(&i); // calls \tcode{f(const int*)} -\end{codeblock} -\end{example} -or, if not that, - -\item -\tcode{S1} -and -\tcode{S2} -are reference bindings~(\ref{dcl.init.ref}), and the types to which the references -refer are the same type except for top-level cv-qualifiers, and the type to -which the reference initialized by -\tcode{S2} -refers is more cv-qualified than the type to which the reference initialized by -\tcode{S1} -refers. -\begin{example} -\begin{codeblock} -int f(const int &); -int f(int &); -int g(const int &); -int g(int); - -int i; -int j = f(i); // calls \tcode{f(int \&)} -int k = g(i); // ambiguous - -struct X { - void f() const; - void f(); -}; -void g(const X& a, X b) { - a.f(); // calls \tcode{X::f() const} - b.f(); // calls \tcode{X::f()} -} -\end{codeblock} -\end{example} -\end{itemize} - -\item -User-defined conversion sequence -\tcode{U1} -is a better conversion sequence than another user-defined conversion -sequence -\tcode{U2} -if they contain the same user-defined conversion function or -constructor or they initialize the same class in an aggregate -initialization and in either case the second standard conversion -sequence of -\tcode{U1} -is better than -the second standard conversion sequence of -\tcode{U2}. -\begin{example} - -\begin{codeblock} -struct A { - operator short(); -} a; -int f(int); -int f(float); -int i = f(a); // calls \tcode{f(int)}, because \tcode{short} $\to$ \tcode{int} is - // better than \tcode{short} $\to$ \tcode{float}. -\end{codeblock} -\end{example} - -\end{itemize} - -\pnum -Standard conversion sequences are ordered by their ranks: an Exact Match is a -better conversion than a Promotion, which is a better conversion than -a Conversion. -Two conversion sequences with the same rank are indistinguishable unless -one of the following rules applies: - -\begin{itemize} -\item -A conversion that does not convert a pointer, -a pointer to member, or \tcode{std::nullptr_t} -to -\tcode{bool} -is better than one that does. - -\item -A conversion that promotes an enumeration whose underlying type is fixed to its underlying -type is better than one that promotes to the promoted underlying type, if the two are -different. - -\item -If class -\tcode{B} -is derived directly or indirectly from class -\tcode{A}, -conversion of -\tcode{B*} -to -\tcode{A*} -is better than conversion of -\tcode{B*} -to -\tcode{void*}, -and conversion of -\tcode{A*} -to -\tcode{void*} -is better than conversion -of -\tcode{B*} -to -\tcode{void*}. -\item -If class -\tcode{B} -is derived directly or indirectly from class -\tcode{A} -and class -\tcode{C} -is derived directly or indirectly from -\tcode{B}, - -\begin{itemize} -\item -conversion of -\tcode{C*} -to -\tcode{B*} -is better than conversion of -\tcode{C*} -to -\tcode{A*}, -\begin{example} - -\begin{codeblock} -struct A {}; -struct B : public A {}; -struct C : public B {}; -C* pc; -int f(A*); -int f(B*); -int i = f(pc); // calls \tcode{f(B*)} -\end{codeblock} -\end{example} - -\item -binding of an expression of type -\tcode{C} -to a reference to type -\tcode{B} -is better than binding an expression of type -\tcode{C} -to a reference to type -\tcode{A}, -\item -conversion of -\tcode{A::*} -to -\tcode{B::*} -is better than conversion of -\tcode{A::*} -to -\tcode{C::*}, -\item -conversion of -\tcode{C} -to -\tcode{B} -is better than conversion of -\tcode{C} -to -\tcode{A}, -\item -conversion of -\tcode{B*} -to -\tcode{A*} -is better than conversion of -\tcode{C*} -to -\tcode{A*}, -\item -binding of an expression of type -\tcode{B} -to a reference to type -\tcode{A} -is better than binding an expression of type -\tcode{C} -to a -reference to type -\tcode{A}, -\item -conversion of -\tcode{B::*} -to -\tcode{C::*} -is better than conversion -of -\tcode{A::*} -to -\tcode{C::*}, -and -\item -conversion of -\tcode{B} -to -\tcode{A} -is better than conversion of -\tcode{C} -to -\tcode{A}. -\end{itemize} - -\begin{note} -Compared conversion sequences will have different source types only in the -context of comparing the second standard conversion sequence of an -initialization by user-defined conversion (see~\ref{over.match.best}); in -all other contexts, the source types will be the same and the target -types will be different. -\end{note} -\end{itemize}% -\indextext{overloading!resolution!implicit conversions and|)}% -\indextext{overloading!resolution|)} - -\rSec1[over.over]{Address of overloaded function}% -\indextext{overloading!address of overloaded function}% -\indextext{overloaded function!address of} - -\pnum -A use of an overloaded function name without arguments is resolved -in certain contexts to a function, a pointer to function or a pointer to -member function for a specific function from the overload set. -A function template name is considered to name a set of overloaded functions -in such contexts. -A function with type \tcode{F} is selected for the function type \tcode{FT} -of the target type required in the context if \tcode{F} -(after possibly applying the function pointer conversion~(\ref{conv.fctptr})) -is identical to \tcode{FT}. -\begin{note} -That is, the class of which the function is a member is ignored when matching a -pointer-to-member-function type. -\end{note} -The target can be - -\begin{itemize} -\item -an object or reference being initialized~(\ref{dcl.init}, \ref{dcl.init.ref}, -\ref{dcl.init.list}), -\item -the left side of an assignment~(\ref{expr.ass}), -\item -a parameter of a function~(\ref{expr.call}), -\item -a parameter of a user-defined operator~(\ref{over.oper}), -\item -the return value of a function, operator function, or conversion~(\ref{stmt.return}), -\item -an explicit type conversion~(\ref{expr.type.conv}, \ref{expr.static.cast}, -\ref{expr.cast}), or -\item -a non-type -\grammarterm{template-parameter}~(\ref{temp.arg.nontype}). -\end{itemize} - -The overloaded function name can be preceded by the -\tcode{\&} -operator. -An overloaded function name shall not be used without arguments in contexts -other than those listed. -\begin{note} -Any redundant set of parentheses surrounding the overloaded function name is -ignored~(\ref{expr.prim}). -\end{note} - -\pnum -If the name is a function template, template argument deduction is -done~(\ref{temp.deduct.funcaddr}), and if the argument deduction succeeds, -the -resulting template argument list is -used to generate a single -function template specialization, -which is added to the set of overloaded functions -considered. -\begin{note} -As described in~\ref{temp.arg.explicit}, if deduction fails and the -function template name is followed by an explicit template argument list, -the -\grammarterm{template-id} -is then examined to see whether it identifies a single function template -specialization. If it does, the -\grammarterm{template-id} -is considered to be an lvalue for that function template specialization. -The target type is not used in that determination. -\end{note} - -\pnum -Non-member functions and static member functions -match targets of function pointer type or -reference to function type. -Non-static member functions match targets of -pointer to member function type. -If a non-static member function is selected, the reference to the overloaded -function name is required to have the form of a pointer to member as -described in~\ref{expr.unary.op}. - -\pnum -If more than one function is selected, any -function template specializations -in the set -are eliminated if the set also contains a function that is not a -function template specialization, and -any given -function template specialization -\tcode{F1} -is eliminated if the set contains a second -function template specialization whose function template -is more specialized than the -function template of -\tcode{F1} -according to -the partial ordering rules of~\ref{temp.func.order}. -After such eliminations, -if any, there shall remain exactly one selected function. - -\pnum -\begin{example} -\begin{codeblock} -int f(double); -int f(int); -int (*pfd)(double) = &f; // selects \tcode{f(double)} -int (*pfi)(int) = &f; // selects \tcode{f(int)} -int (*pfe)(...) = &f; // error: type mismatch -int (&rfi)(int) = f; // selects \tcode{f(int)} -int (&rfd)(double) = f; // selects \tcode{f(double)} -void g() { - (int (*)(int))&f; // cast expression as selector -} -\end{codeblock} - -The initialization of -\tcode{pfe} -is ill-formed because no -\tcode{f()} -with type -\tcode{int(...)} -has been declared, and not because of any ambiguity. -For another example, - -\begin{codeblock} -struct X { - int f(int); - static int f(long); -}; - -int (X::*p1)(int) = &X::f; // OK -int (*p2)(int) = &X::f; // error: mismatch -int (*p3)(long) = &X::f; // OK -int (X::*p4)(long) = &X::f; // error: mismatch -int (X::*p5)(int) = &(X::f); // error: wrong syntax for - // pointer to member -int (*p6)(long) = &(X::f); // OK -\end{codeblock} -\end{example} - -\pnum -\begin{note} -If -\tcode{f()} -and -\tcode{g()} -are both overloaded functions, the -cross product of possibilities must be considered -to resolve -\tcode{f(\&g)}, -or the equivalent expression -\tcode{f(g)}. -\end{note} - -\pnum -\indextext{conversion!overload resolution and pointer}% -\begin{note} -Even if \tcode{B} is a public base of \tcode{D}, -we have - -\begin{codeblock} -D* f(); -B* (*p1)() = &f; // error - -void g(D*); -void (*p2)(B*) = &g; // error -\end{codeblock} -\end{note} - -\rSec1[over.oper]{Overloaded operators}% -\indextext{overloading!operator|(}% -\indextext{overloaded operator|see{overloading, operator}}% -\indextext{operator overloading|see{overloading, operator}} - -\pnum -\indextext{operator!overloaded}% -\indextext{function!operator}% -A function declaration having one of the following -\grammarterm{operator-function-id}{s} -as its name declares an -\term{operator function}. -A function template declaration having one of the -following \grammarterm{operator-function-id}{s} as its name -declares an \term{operator function template}. A specialization -of an operator function template is also an operator function. -An operator function is said to -\term{implement} -the operator named in its -\grammarterm{operator-function-id}. - -\begin{bnf} -\nontermdef{operator-function-id}\br - \terminal{operator} operator -\end{bnf} - -\begin{bnfkeywordtab} -\nontermdef{operator} \textnormal{one of}\br -\>new\>delete\>new[]\>delete[]\br -\>+\>-\>*\>/\>\%\>\caret\>\&\>|\>\~\br -\>!\>=\><\>>\>+=\>-=\>*=\>/=\>\%=\br -\>\caret=\>\&=\>|=\><<\>>>\>>>=\><<=\>={=}\>!=\br -\><=\>>=\>\&\&\>|{|}\>++\>-{-}\>,\>->*\>->\br -\>(\,)\>[\,] -\end{bnfkeywordtab} - -\begin{note} -The last two operators are function call~(\ref{expr.call}) -and subscripting~(\ref{expr.sub}). -The operators -\tcode{new[]}, -\tcode{delete[]}, -\tcode{()}, -and -\tcode{[]} -are formed from more than one token. -\end{note} -\indextext{operator!subscripting}% -\indextext{operator!function call}% - -\pnum -Both the unary and binary forms of - -\begin{codeblock} -+ - * & -\end{codeblock} - -can be overloaded. - -\pnum -\indextext{restriction!operator overloading}% -The following operators cannot be overloaded: - -\begin{codeblock} -. .* :: ?: -\end{codeblock} - -nor can the preprocessing symbols -\tcode{\#} -and -\tcode{\#\#} -(Clause~\ref{cpp}). - -\pnum -\indextext{call!operator function}% -Operator functions are usually not called directly; instead they are invoked -to evaluate the operators they implement~(\ref{over.unary} -- \ref{over.inc}). -They can be explicitly called, however, using the -\grammarterm{operator-function-id} -as the name of the function in the function call syntax~(\ref{expr.call}). -\begin{example} - -\begin{codeblock} -complex z = a.operator+(b); // \tcode{complex z = a+b;} -void* p = operator new(sizeof(int)*n); -\end{codeblock} -\end{example} - -\pnum -The allocation and deallocation functions, -\tcode{operator} -\tcode{new}, -\tcode{operator} -\tcode{new[]}, -\tcode{operator} -\tcode{delete} -and -\tcode{operator} -\tcode{de\-lete\brk[]}, -are described completely in~\ref{basic.stc.dynamic}. -The attributes and restrictions -found in the rest of this subclause do not apply to them unless explicitly -stated in~\ref{basic.stc.dynamic}. - -\pnum -\indextext{restriction!overloading}% -An operator function -shall either be a non-static member function or be a non-member function that -has at least one parameter whose type is a class, a reference to a class, an -enumeration, or a reference to an enumeration. -It is not possible to change the precedence, grouping, or number of operands -of operators. -The meaning of the operators -\tcode{=}, -(unary) -\tcode{\&}, -and -\tcode{,} -(comma), predefined for each type, can be changed for specific -class and enumeration types by -defining operator functions that implement these operators. -\indextext{overloaded operator!inheritance of}% -Operator functions are inherited in the same manner as other base class -functions. - -\pnum -\indextext{operator}% -The identities among certain predefined operators applied to basic types -(for example, -\tcode{++a} $\equiv$ -\tcode{a+=1}) -need not hold for operator functions. -Some predefined operators, such as -\tcode{+=}, -require an operand to be an lvalue when applied to basic types; -this is not required by operator functions. - -\pnum -\indextext{argument!overloaded operator and default}% -An operator function cannot have default arguments~(\ref{dcl.fct.default}), -except where explicitly stated below. -Operator -functions cannot have more or fewer parameters than the -number required for the corresponding operator, as -described in the rest of this subclause. - -\pnum -Operators not mentioned explicitly in subclauses~\ref{over.ass} through~\ref{over.inc} -act as ordinary unary and binary -operators obeying the rules of~\ref{over.unary} or~\ref{over.binary}.% -\indextext{overloading!resolution!best viable function|)}% -\indextext{overloading!resolution!viable functions|)} - -\rSec2[over.unary]{Unary operators}% -\indextext{unary operator!overloaded}% -\indextext{overloading!unary operator} - -\pnum -A prefix unary operator shall be implemented by a -non-static member function~(\ref{class.mfct}) with no parameters or a -non-member function with one parameter. -\indextext{unary operator!interpretation of}% -Thus, for any prefix unary operator -\tcode{@}, -\tcode{@x} -can be interpreted as either -\tcode{x.op\-er\-a\-tor@()} -or -\tcode{operator@(x)}. -If both forms of the operator function have been declared, -the rules in~\ref{over.match.oper} determine which, if any, interpretation is -used. -See~\ref{over.inc} for an explanation of the postfix unary operators -\tcode{++} -and -\tcode{\dcr}. - -\pnum -The unary and binary forms of the same operator are considered to have -the same name. -\begin{note} -Consequently, a unary operator can hide a binary -operator from an enclosing scope, and vice versa. -\end{note} - -\rSec2[over.binary]{Binary operators}% -\indextext{binary operator!overloaded}% -\indextext{overloading!binary operator} - -\pnum -A binary operator shall be implemented either by a non-static member -function~(\ref{class.mfct}) -with one parameter or by a non-member function with two parameters. -\indextext{binary operator!interpretation of}% -Thus, for any binary operator -\tcode{@}, -\tcode{x@y} -can be interpreted as either -\tcode{x.op\-er\-a\-tor\-@(y)} -or -\tcode{operator@(x,y)}. -If both forms of the operator function have been declared, -the rules in~\ref{over.match.oper} determine which, if any, interpretation is -used. - -\rSec2[over.ass]{Assignment} -\indextext{assignment operator!overloaded}% -\indextext{overloading!assignment operator} - -\pnum -An assignment operator shall be implemented by a -non-static member function with -exactly one parameter. -Because a copy assignment operator -\tcode{operator=} -is implicitly declared for a class if not declared by the user~(\ref{class.copy}), -a base class assignment operator is always hidden by the copy assignment -operator of the derived class. - -\pnum -Any assignment operator, even the copy and move assignment operators, can be virtual. -\begin{note} -For a derived class -\tcode{D} -with a base class -\tcode{B} -for which a virtual copy/move assignment has been declared, -the copy/move assignment operator in -\tcode{D} -does not override -\tcode{B}'s -virtual copy/move assignment operator. -\begin{example} - -\begin{codeblock} -struct B { - virtual int operator= (int); - virtual B& operator= (const B&); -}; -struct D : B { - virtual int operator= (int); - virtual D& operator= (const B&); -}; - -D dobj1; -D dobj2; -B* bptr = &dobj1; -void f() { - bptr->operator=(99); // calls \tcode{D::operator=(int)} - *bptr = 99; // ditto - bptr->operator=(dobj2); // calls \tcode{D::operator=(const B\&)} - *bptr = dobj2; // ditto - dobj1 = dobj2; // calls implicitly-declared \tcode{D::operator=(const D\&)} -} -\end{codeblock} -\end{example} -\end{note} - -\rSec2[over.call]{Function call}% -\indextext{function call operator!overloaded}% -\indextext{overloading!function call operator} - -\pnum -\tcode{operator()} -shall be a non-static member function with an arbitrary number of -parameters. -It can have default arguments. -It implements the function call syntax - -\begin{ncsimplebnf} -postfix-expression \terminal{(} expression-list\opt{} \terminal{)} -\end{ncsimplebnf} - -where the -\grammarterm{postfix-expression} -evaluates to a class object and the possibly empty -\grammarterm{expression-list} -matches the parameter list of an -\tcode{operator()} -member function of the class. -Thus, a call -\tcode{x(arg1,...)} -is interpreted as -\tcode{x.op\-er\-a\-tor()(arg1, ...)} -for a class object -\tcode{x} -of type -\tcode{T} -if -\tcode{T::operator()(T1,} -\tcode{T2,} -\tcode{T3)} -exists and if the operator is selected as the best match function by -the overload resolution mechanism~(\ref{over.match.best}). - -\rSec2[over.sub]{Subscripting}% -\indextext{subscripting operator!overloaded}% -\indextext{overloading!subscripting operator} - -\pnum -\tcode{operator[]} -shall be a non-static member function with exactly one parameter. -It implements the subscripting syntax - -\begin{ncsimplebnf} -postfix-expression \terminal{[} expr-or-braced-init-list \terminal{]} -\end{ncsimplebnf} - -Thus, a subscripting expression -\tcode{x[y]} -is interpreted as -\tcode{x.operator[](y)} -for a class object -\tcode{x} -of type -\tcode{T} -if -\tcode{T::op\-er\-a\-tor[]\-(T1)} -exists and if the operator is selected as the best match function by -the overload resolution mechanism~(\ref{over.match.best}). -\begin{example} -\begin{codeblock} -struct X { - Z operator[](std::initializer_list); -}; -X x; -x[{1,2,3}] = 7; // OK: meaning \tcode{x.operator[](\{1,2,3\})} -int a[10]; -a[{1,2,3}] = 7; // error: built-in subscript operator -\end{codeblock} -\end{example} - -\rSec2[over.ref]{Class member access} -\indextext{member access operator!overloaded}% -\indextext{overloading!member access operator} - -\pnum -\tcode{operator->} -shall be a non-static member function taking no parameters. -It implements the class member access syntax that -uses \tcode{->}. - -\begin{ncsimplebnf} -postfix-expression \terminal{->} \terminal{template\opt} id-expression\\ -postfix-expression \terminal{->} pseudo-destructor-name -\end{ncsimplebnf} - -An expression -\tcode{x->m} -is interpreted as -\tcode{(x.operator->())->m} -for a class object -\tcode{x} -of type -\tcode{T} -if -\tcode{T::operator->()} -exists and if the operator is selected as the best match function by -the overload resolution mechanism~(\ref{over.match}). - -\rSec2[over.inc]{Increment and decrement} -\indextext{increment operator!overloaded|see{overloading, increment operator}}% -\indextext{decrement operator!overloaded|see{overloading, decrement operator}}% -\indextext{prefix ++ and -{-} overloading@prefix \tcode{++} and \tcode{\dcr}!overloading}% -\indextext{postfix ++ and -{-} overloading@postfix \tcode{++} and \tcode{\dcr}!overloading}% - -\pnum -The user-defined function called -\tcode{operator++} -implements the prefix and postfix -\tcode{++} -operator. -If this function is a non-static member function with no parameters, or a non-member -function with one parameter, -it defines the prefix increment operator -\tcode{++} -for objects of that type. -If the function is a non-static member function with one parameter (which shall be of type -\tcode{int}) -or a non-member function with two parameters (the second of which shall be of type -\tcode{int}), -it defines the postfix increment operator -\tcode{++} -for objects of that type. -When the postfix increment is called as a result of using the -\tcode{++} -operator, the -\tcode{int} -argument will have value zero.\footnote{Calling -\tcode{operator++} -explicitly, as in expressions like -\tcode{a.operator++(2)}, -has no special properties: -The argument to -\tcode{operator++} -is -\tcode{2}.} -\begin{example} - -\begin{codeblock} -struct X { - X& operator++(); // prefix \tcode{++a} - X operator++(int); // postfix \tcode{a++} -}; - -struct Y { }; -Y& operator++(Y&); // prefix \tcode{++b} -Y operator++(Y&, int); // postfix \tcode{b++} - -void f(X a, Y b) { - ++a; // \tcode{a.operator++();} - a++; // \tcode{a.operator++(0);} - ++b; // \tcode{operator++(b);} - b++; // \tcode{operator++(b, 0);} - - a.operator++(); // explicit call: like \tcode{++a;} - a.operator++(0); // explicit call: like \tcode{a++;} - operator++(b); // explicit call: like \tcode{++b;} - operator++(b, 0); // explicit call: like \tcode{b++;} -} -\end{codeblock} -\end{example} - -\pnum -The prefix and postfix decrement operators -\tcode{-{-}} -are handled analogously. - -\rSec2[over.literal]{User-defined literals}% -\indextext{user-defined literal!overloaded}% -\indextext{overloading!user-defined literal} - -\begin{bnf} -\nontermdef{literal-operator-id}\br - \terminal{operator} string-literal identifier\br - \terminal{operator} user-defined-string-literal -\end{bnf} - -\pnum -The \grammarterm{string-literal} or \grammarterm{user-defined-string-literal} -in a \grammarterm{literal-operator-id} shall have no -\grammarterm{encoding-prefix} and shall contain no characters other than the -implicit terminating \tcode{'\textbackslash 0'}. -The \grammarterm{ud-suffix} of the \grammarterm{user-defined-string-literal} or -the \grammarterm{identifier} in a \grammarterm{literal-operator-id} is called a -\term{literal suffix identifier}. -Some literal suffix identifiers are reserved for future standardization; -see~\ref{usrlit.suffix}. A declaration whose \grammarterm{literal-operator-id} uses -such a literal suffix identifier is ill-formed, no diagnostic required. - -\pnum -A declaration whose \grammarterm{declarator-id} is a -\grammarterm{literal-operator-id} shall be a declaration of a namespace-scope -function or function template (it could be a friend -function~(\ref{class.friend})), an explicit instantiation or specialization of a -function template, or a \grammarterm{using-declaration}~(\ref{namespace.udecl}). -A function declared with a \grammarterm{literal-operator-id} is a \term{literal -operator}. A function template declared with a \grammarterm{literal-operator-id} -is a \term{literal operator template}. - -\pnum -The declaration of a literal operator shall have a -\grammarterm{parameter-declaration-clause} equivalent to one of the following: - -\begin{codeblock} -const char* -unsigned long long int -long double -char -wchar_t -char16_t -char32_t -const char*, std::size_t -const wchar_t*, std::size_t -const char16_t*, std::size_t -const char32_t*, std::size_t -\end{codeblock} - -If a parameter has a default argument~(\ref{dcl.fct.default}), the program is -ill-formed. - -\pnum -A \term{raw literal operator} is a literal operator with a single parameter -whose type is \tcode{const char*}. - -\pnum -The declaration of a literal operator template shall have an empty -\grammarterm{parameter-declaration-clause} and its -\grammarterm{template-parameter-list} shall have a single -\grammarterm{template-parameter} that is a non-type template parameter -pack (\ref{temp.variadic}) with element type \tcode{char}. - -\pnum -Literal operators and literal operator templates shall not have C language linkage. - -\pnum -\begin{note} Literal operators and literal operator templates are usually invoked -implicitly through user-defined literals~(\ref{lex.ext}). However, except for -the constraints described above, they are ordinary namespace-scope functions and -function templates. In particular, they are looked up like ordinary functions -and function templates and they follow the same overload resolution rules. Also, -they can be declared \tcode{inline} or \tcode{constexpr}, they may have internal -or external linkage, they can be called explicitly, their addresses can be -taken, etc. \end{note} - -\pnum -\begin{example} -\begin{codeblock} -void operator "" _km(long double); // OK -string operator "" _i18n(const char*, std::size_t); // OK -template double operator "" _\u03C0(); // OK: UCN for lowercase pi -float operator ""_e(const char*); // OK -float operator ""E(const char*); // error: reserved literal suffix~(\ref{usrlit.suffix}, \ref{lex.ext}) -double operator""_Bq(long double); // OK: does not use the reserved identifier \tcode{_Bq}~(\ref{lex.name}) -double operator"" _Bq(long double); // uses the reserved identifier \tcode{_Bq}~(\ref{lex.name}) -float operator " " B(const char*); // error: non-empty \grammarterm{string-literal} -string operator "" 5X(const char*, std::size_t); // error: invalid literal suffix identifier -double operator "" _miles(double); // error: invalid \grammarterm{parameter-declaration-clause} -template int operator "" _j(const char*); // error: invalid \grammarterm{parameter-declaration-clause} -extern "C" void operator "" _m(long double); // error: C language linkage -\end{codeblock} -\end{example}% -\indextext{overloading!operator|)} - -\rSec1[over.built]{Built-in operators}% -\indextext{overloading!built-in operators and} - -\pnum -The candidate operator functions that represent the built-in operators -defined in Clause~\ref{expr} are specified in this subclause. -These candidate -functions participate in the operator overload resolution process as -described in~\ref{over.match.oper} and are used for no other purpose. -\begin{note} -Because built-in operators take only operands with non-class type, -and operator overload resolution occurs only when an operand expression -originally has class or enumeration type, -operator overload resolution can resolve to a built-in operator only -when an operand has a class type that has a user-defined conversion to -a non-class type appropriate for the operator, or when an operand has -an enumeration type that can be converted to a type appropriate -for the operator. -Also note that some of the candidate operator functions given in this subclause are -more permissive than the built-in operators themselves. -As -described in~\ref{over.match.oper}, after a built-in operator is selected -by overload resolution the expression is subject to the requirements for -the built-in operator given in Clause~\ref{expr}, and therefore to any -additional semantic constraints given there. -If there is a user-written -candidate with the same name and parameter types as a built-in -candidate operator function, the built-in operator function -is hidden and is not included in the set of candidate functions. -\end{note} - -\pnum -\indextext{type!integral!promoted}% -\indextext{type!arithmetic!promoted}% -In this subclause, the term -\defn{promoted integral type} -is used to refer to those integral types which are preserved by -integral promotion~(\ref{conv.prom}) (including e.g. -\tcode{int} -and -\tcode{long} -but excluding e.g. -\tcode{char}). -Similarly, the term -\defn{promoted arithmetic type} -refers to floating types plus promoted integral types. -\begin{note} -In all cases where a promoted integral type or promoted arithmetic type is -required, an operand of enumeration type will be acceptable by way of the -integral promotions. -\end{note} - -\pnum -In the remainder of this section, \cvqual{vq} represents either -\tcode{volatile} or no cv-qualifier. - -\pnum -For every pair -(\tcode{\placeholder{T}}, -\cvqual{vq}), -where -\tcode{\placeholder{T}} -is an arithmetic type other than \tcode{bool}, -there exist candidate operator functions of the form - -\begin{codeblock} -@\cvqual{vq} \placeholder{T}@& operator++(@\cvqual{vq} \placeholder{T}@&); -@\placeholder{T}@ operator++(@\cvqual{vq} \placeholder{T}@&, int); -\end{codeblock} - -\pnum -For every pair -(\tcode{\placeholder{T}}, -\cvqual{vq}), -where -\tcode{\placeholder{T}} -is an arithmetic type other than -\tcode{bool}, -there exist candidate operator functions of the form - -\begin{codeblock} -@\cvqual{vq} \placeholder{T}@& operator--(@\cvqual{vq} \placeholder{T}@&); -@\placeholder{T}@ operator--(@\cvqual{vq} \placeholder{T}@&, int); -\end{codeblock} - -\pnum -For every pair -(\tcode{\placeholder{T}}, -\cvqual{vq}), -where -\tcode{\placeholder{T}} -is a cv-qualified or cv-unqualified object type, -there exist candidate operator functions of the form - -\begin{codeblock} -@\placeholder{T}@*@\cvqual{vq}@& operator++(@\placeholder{T}@*@\cvqual{vq}@&); -@\placeholder{T}@*@\cvqual{vq}@& operator--(@\placeholder{T}@*@\cvqual{vq}@&); -@\placeholder{T}@* operator++(@\placeholder{T}@*@\cvqual{vq}@&, int); -@\placeholder{T}@* operator--(@\placeholder{T}@*@\cvqual{vq}@&, int); -\end{codeblock} - -\pnum -For every cv-qualified or cv-unqualified object type -\tcode{\placeholder{T}}, -there exist candidate operator functions of the form - -\begin{codeblock} -@\placeholder{T}@& operator*(@\placeholder{T}@*); -\end{codeblock} - -\pnum -For every function type -\tcode{\placeholder{T}} that does not have cv-qualifiers or a \grammarterm{ref-qualifier}, -there exist candidate operator functions of the form - -\begin{codeblock} -@\placeholder{T}@& operator*(@\placeholder{T}@*); -\end{codeblock} - -\pnum -For every type \tcode{\placeholder{T}} there exist candidate operator functions of the form - -\begin{codeblock} -@\placeholder{T}@* operator+(@\placeholder{T}@*); -\end{codeblock} - -\pnum -For every promoted arithmetic type -\tcode{\placeholder{T}}, -there exist candidate operator functions of the form - -\begin{codeblock} -@\placeholder{T}@ operator+(@\placeholder{T}@); -@\placeholder{T}@ operator-(@\placeholder{T}@); -\end{codeblock} - -\pnum -For every promoted integral type -\tcode{\placeholder{T}}, -there exist candidate operator functions of the form - -\begin{codeblock} -@\placeholder{T}@ operator~(@\placeholder{T}@); -\end{codeblock} - -\pnum -For every quintuple -(\tcode{\placeholder{C1}}, -\tcode{\placeholder{C2}}, -\tcode{\placeholder{T}}, -\cvqual{cv1}, -\cvqual{cv2}), -where -\tcode{\placeholder{C2}} -is a class type, -\tcode{\placeholder{C1}} -is the same type as \tcode{\placeholder{C2}} or is a derived class of \tcode{\placeholder{C2}}, and -\tcode{\placeholder{T}} -is an object type or a function type, -there exist candidate operator functions of the form - -\begin{codeblock} -@\cvqual{cv12} \placeholder{T}@& operator->*(@\cvqual{cv1} \placeholder{C1}@*, @\cvqual{cv2} \placeholder{T C2}@::*); -\end{codeblock} - -where \cvqual{cv12} is the union of \cvqual{cv1} and \cvqual{cv2}. -The return type is shown for exposition only; see~\ref{expr.mptr.oper} for the -determination of the operator's result type. - -\pnum -For every pair of promoted arithmetic types -\tcode{\placeholder{L}} -and -\tcode{\placeholder{R}}, -there exist candidate operator functions of the form - -\begin{codeblock} -@\placeholder{LR}@ operator*(@\placeholder{L}@, @\placeholder{R}@); -@\placeholder{LR}@ operator/(@\placeholder{L}@, @\placeholder{R}@); -@\placeholder{LR}@ operator+(@\placeholder{L}@, @\placeholder{R}@); -@\placeholder{LR}@ operator-(@\placeholder{L}@, @\placeholder{R}@); -bool operator<(@\placeholder{L}@, @\placeholder{R}@); -bool operator>(@\placeholder{L}@, @\placeholder{R}@); -bool operator<=(@\placeholder{L}@, @\placeholder{R}@); -bool operator>=(@\placeholder{L}@, @\placeholder{R}@); -bool operator==(@\placeholder{L}@, @\placeholder{R}@); -bool operator!=(@\placeholder{L}@, @\placeholder{R}@); -\end{codeblock} - -where -\tcode{\placeholder{LR}} -is the result of the usual arithmetic conversions between types -\tcode{\placeholder{L}} -and -\tcode{\placeholder{R}}. - -\pnum -For every cv-qualified or cv-unqualified object type -\tcode{\placeholder{T}} -there exist candidate operator functions of the form - -\begin{codeblock} -@\placeholder{T}@* operator+(@\placeholder{T}@*, std::ptrdiff_t); -@\placeholder{T}@& operator[](@\placeholder{T}@*, std::ptrdiff_t); -@\placeholder{T}@* operator-(@\placeholder{T}@*, std::ptrdiff_t); -@\placeholder{T}@* operator+(std::ptrdiff_t, @\placeholder{T}@*); -@\placeholder{T}@& operator[](std::ptrdiff_t, @\placeholder{T}@*); -\end{codeblock} - -\pnum -For every -\tcode{\placeholder{T}}, -where -\tcode{\placeholder{T}} -is a pointer to object type, -there exist candidate operator functions of the form - -\begin{codeblock} -std::ptrdiff_t operator-(@\placeholder{T}@, @\placeholder{T}@); -\end{codeblock} - -\pnum -For every \tcode{\placeholder{T}}, where \tcode{\placeholder{T}} is an enumeration type or a pointer type, -there exist candidate operator functions of the form - -\begin{codeblock} -bool operator<(@\placeholder{T}@, @\placeholder{T}@); -bool operator>(@\placeholder{T}@, @\placeholder{T}@); -bool operator<=(@\placeholder{T}@, @\placeholder{T}@); -bool operator>=(@\placeholder{T}@, @\placeholder{T}@); -bool operator==(@\placeholder{T}@, @\placeholder{T}@); -bool operator!=(@\placeholder{T}@, @\placeholder{T}@); -\end{codeblock} - -\pnum -For every pointer to member type \tcode{\placeholder{T}} or type \tcode{std::nullptr_t} there -exist candidate operator functions of the form - -\begin{codeblock} -bool operator==(@\placeholder{T}@, @\placeholder{T}@); -bool operator!=(@\placeholder{T}@, @\placeholder{T}@); -\end{codeblock} - -\pnum -For every pair of promoted integral types -\tcode{\placeholder{L}} -and -\tcode{\placeholder{R}}, -there exist candidate operator functions of the form - -\begin{codeblock} -@\placeholder{LR}@ operator%(@\placeholder{L}@, @\placeholder{R}@); -@\placeholder{LR}@ operator&(@\placeholder{L}@, @\placeholder{R}@); -@\placeholder{LR}@ operator^(@\placeholder{L}@, @\placeholder{R}@); -@\placeholder{LR}@ operator|(@\placeholder{L}@, @\placeholder{R}@); -@\placeholder{L}@ operator<<(@\placeholder{L}@, @\placeholder{R}@); -@\placeholder{L}@ operator>>(@\placeholder{L}@, @\placeholder{R}@); -\end{codeblock} - -where -\tcode{\placeholder{LR}} -is the result of the usual arithmetic conversions between types -\tcode{\placeholder{L}} -and -\tcode{\placeholder{R}}. - -\pnum -For every triple -(\tcode{\placeholder{L}}, -\cvqual{vq}, -\tcode{\placeholder{R}}), -where -\tcode{\placeholder{L}} -is an arithmetic type, -and -\tcode{\placeholder{R}} -is a promoted arithmetic type, -there exist candidate operator functions of the form - -\begin{codeblock} -@\cvqual{vq} \placeholder{L}@& operator=(@\cvqual{vq} \placeholder{L}@&, @\placeholder{R}@); -@\cvqual{vq} \placeholder{L}@& operator*=(@\cvqual{vq} \placeholder{L}@&, @\placeholder{R}@); -@\cvqual{vq} \placeholder{L}@& operator/=(@\cvqual{vq} \placeholder{L}@&, @\placeholder{R}@); -@\cvqual{vq} \placeholder{L}@& operator+=(@\cvqual{vq} \placeholder{L}@&, @\placeholder{R}@); -@\cvqual{vq} \placeholder{L}@& operator-=(@\cvqual{vq} \placeholder{L}@&, @\placeholder{R}@); -\end{codeblock} - -\pnum -For every pair (\tcode{\placeholder{T}}, \cvqual{vq}), -where \tcode{\placeholder{T}} is any type, -there exist candidate operator functions of the form - -\begin{codeblock} -@\placeholder{T}@*@\cvqual{vq}@& operator=(@\placeholder{T}@*@\cvqual{vq}@&, @\placeholder{T}@*); -\end{codeblock} - -\pnum -For every pair -(\tcode{\placeholder{T}}, -\cvqual{vq}), -where -\tcode{\placeholder{T}} -is an enumeration or pointer to member type, -there exist candidate operator functions of the form - -\begin{codeblock} -@\cvqual{vq} \placeholder{T}@& operator=(@\cvqual{vq} \placeholder{T}@&, @\placeholder{T}@); -\end{codeblock} - -\pnum -For every pair -(\tcode{\placeholder{T}}, -\cvqual{vq}), -where -\tcode{\placeholder{T}} -is a cv-qualified or cv-unqualified object type, -there exist candidate operator functions of the form - -\begin{codeblock} -@\placeholder{T}@*@\cvqual{vq}@& operator+=(@\placeholder{T}@*@\cvqual{vq}@&, std::ptrdiff_t); -@\placeholder{T}@*@\cvqual{vq}@& operator-=(@\placeholder{T}@*@\cvqual{vq}@&, std::ptrdiff_t); -\end{codeblock} - -\pnum -For every triple -(\tcode{\placeholder{L}}, -\cvqual{vq}, -\tcode{\placeholder{R}}), -where -\tcode{\placeholder{L}} -is an integral type, and -\tcode{\placeholder{R}} -is a promoted integral type, -there exist candidate operator functions of the form - -\begin{codeblock} -@\cvqual{vq} \placeholder{L}@& operator%=(@\cvqual{vq} \placeholder{L}@&, @\placeholder{R}@); -@\cvqual{vq} \placeholder{L}@& operator<<=(@\cvqual{vq} \placeholder{L}@&, @\placeholder{R}@); -@\cvqual{vq} \placeholder{L}@& operator>>=(@\cvqual{vq} \placeholder{L}@&, @\placeholder{R}@); -@\cvqual{vq} \placeholder{L}@& operator&=(@\cvqual{vq} \placeholder{L}@&, @\placeholder{R}@); -@\cvqual{vq} \placeholder{L}@& operator^=(@\cvqual{vq} \placeholder{L}@&, @\placeholder{R}@); -@\cvqual{vq} \placeholder{L}@& operator|=(@\cvqual{vq} \placeholder{L}@&, @\placeholder{R}@); -\end{codeblock} - -\pnum -There also exist candidate operator functions of the form - -\begin{codeblock} -bool operator!(bool); -bool operator&&(bool, bool); -bool operator||(bool, bool); -\end{codeblock} - -\pnum -For every pair of promoted arithmetic types -\tcode{\placeholder{L}} -and -\tcode{\placeholder{R}}, -there exist candidate operator functions of the form - -\begin{codeblock} -@\placeholder{LR}@ operator?:(bool, @\placeholder{L}@, @\placeholder{R}@); -\end{codeblock} - -where -\tcode{\placeholder{LR}} -is the result of the usual arithmetic conversions between types -\tcode{\placeholder{L}} -and -\tcode{\placeholder{R}}. -\begin{note} -As with all these descriptions of candidate functions, this declaration serves -only to describe the built-in operator for purposes of overload resolution. -The operator -``\tcode{?:}'' -cannot be overloaded. -\end{note} - -\pnum -For every type -\tcode{\placeholder{T}}, -where -\tcode{\placeholder{T}} -is a pointer, pointer-to-member, or scoped enumeration type, there exist candidate operator -functions of the form - -\begin{codeblock} -@\placeholder{T}@ operator?:(bool, @\placeholder{T}@, @\placeholder{T}@); -\end{codeblock}% -\indextext{overloading|)} From 355a20beb12ba9c26cb09d41159f7f68238dab7d Mon Sep 17 00:00:00 2001 From: timsong-cpp Date: Tue, 1 Aug 2017 04:14:14 -0400 Subject: [PATCH 04/79] [defns.well.formed] remove full stop --- source/intro.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/intro.tex b/source/intro.tex index c43e357c35..0d4ebd2b7b 100644 --- a/source/intro.tex +++ b/source/intro.tex @@ -307,7 +307,7 @@ \indexdefn{program!well-formed}% \definition{well-formed program}{defns.well.formed} \Cpp program constructed according to the syntax rules, diagnosable -semantic rules, and the one-definition rule\iref{basic.def.odr}.% +semantic rules, and the one-definition rule\iref{basic.def.odr}% \indextext{definitions|)} \rSec0[intro]{General principles} From a35fb3e2db1f76777bd1d509456fb10beed6ce0e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thomas=20K=C3=B6ppe?= Date: Tue, 1 Aug 2017 21:44:01 +0100 Subject: [PATCH 05/79] [util.smartptr.shared.create] Fix macro application --- source/utilities.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/source/utilities.tex b/source/utilities.tex index 3e1176a7e9..d490417fab 100644 --- a/source/utilities.tex +++ b/source/utilities.tex @@ -9761,9 +9761,9 @@ \indexlibrary{\idxcode{allocate_shared}}% \begin{itemdecl} template - shared_ptr make_shared(\placeholder{args}); + shared_ptr make_shared(@\placeholdernc{args}@); template - shared_ptr allocate_shared(const A& a, \placeholder{args}); + shared_ptr allocate_shared(const A& a, @\placeholdernc{args}@); \end{itemdecl} \begin{itemdescr} From e3b4927ea0f4e8c8bf1f7461226c729b4e2c00be Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thomas=20K=C3=B6ppe?= Date: Tue, 1 Aug 2017 22:06:30 +0100 Subject: [PATCH 06/79] [memory.syn, util.smartptr.shared] Add missing {make,allocate}_shared declarations to synopsis We list those functions in two places: the main synopsis in [memory.syn], and also a smaller subset in [util.smartptr.shared] just for shared_ptr. Also contains some minor presentational improvements for both instances. Fixes #1697. --- source/utilities.tex | 55 +++++++++++++++++++++++++++++++------------- 1 file changed, 39 insertions(+), 16 deletions(-) diff --git a/source/utilities.tex b/source/utilities.tex index d490417fab..27060bf075 100644 --- a/source/utilities.tex +++ b/source/utilities.tex @@ -6666,7 +6666,8 @@ template unique_ptr make_unique(size_t n); template @\unspec@ make_unique(Args&&...) = delete; - template void swap(unique_ptr& x, unique_ptr& y) noexcept; + template + void swap(unique_ptr& x, unique_ptr& y) noexcept; template bool operator==(const unique_ptr& x, const unique_ptr& y); @@ -6714,9 +6715,30 @@ // \ref{util.smartptr.shared.create}, \tcode{shared_ptr} creation template - shared_ptr make_shared(Args&&... args); + shared_ptr make_shared(Args&&... args); // \tcode{T} is not array template - shared_ptr allocate_shared(const A& a, Args&&... args); + shared_ptr allocate_shared(const A& a, Args&&... args); // \tcode{T} is not array + + template + shared_ptr make_shared(size_t N); // \tcode{T} is \tcode{U[]} + template + shared_ptr allocate_shared(const A& a, size_t N); // \tcode{T} is \tcode{U[]} + + template + shared_ptr make_shared(); // \tcode{T} is \tcode{U[N]} + template + shared_ptr allocate_shared(const A& a); // \tcode{T} is \tcode{U[N]} + + template + shared_ptr make_shared(size_t N, const remove_extent_t& u); // \tcode{T} is \tcode{U[]} + template + shared_ptr allocate_shared(const A& a, size_t N, + const remove_extent_t& u); // \tcode{T} is \tcode{U[]} + + template shared_ptr + make_shared(const remove_extent_t& u); // \tcode{T} is \tcode{U[N]} + template + shared_ptr allocate_shared(const A& a, const remove_extent_t& u); // \tcode{T} is \tcode{U[N]} // \ref{util.smartptr.shared.cmp}, \tcode{shared_ptr} comparisons template @@ -7987,7 +8009,8 @@ template unique_ptr make_unique(size_t n); template @\unspec@ make_unique(Args&&...) = delete; - template void swap(unique_ptr& x, unique_ptr& y) noexcept; + template + void swap(unique_ptr& x, unique_ptr& y) noexcept; template bool operator==(const unique_ptr& x, const unique_ptr& y); @@ -8026,7 +8049,6 @@ bool operator>=(const unique_ptr& x, nullptr_t); template bool operator>=(nullptr_t, const unique_ptr& y); - } \end{codeblock} @@ -9167,29 +9189,30 @@ // \ref{util.smartptr.shared.create}, \tcode{shared_ptr} creation template - shared_ptr make_shared(Args&&... args); // \tcode{T} is not array + shared_ptr make_shared(Args&&... args); // \tcode{T} is not array template - shared_ptr allocate_shared(const A& a, Args&&... args); // \tcode{T} is not array + shared_ptr allocate_shared(const A& a, Args&&... args); // \tcode{T} is not array - template shared_ptr make_shared(size_t N); // \tcode{T} is \tcode{U[]} + template + shared_ptr make_shared(size_t N); // \tcode{T} is \tcode{U[]} template - shared_ptr allocate_shared(const A& a, size_t N); // \tcode{T} is \tcode{U[]} + shared_ptr allocate_shared(const A& a, size_t N); // \tcode{T} is \tcode{U[]} - template shared_ptr make_shared(); // \tcode{T} is \tcode{U[N]} + template + shared_ptr make_shared(); // \tcode{T} is \tcode{U[N]} template - shared_ptr allocate_shared(const A& a); // \tcode{T} is \tcode{U[N]} + shared_ptr allocate_shared(const A& a); // \tcode{T} is \tcode{U[N]} template - shared_ptr make_shared(size_t N, const remove_extent_t& u); // \tcode{T} is \tcode{U[]} + shared_ptr make_shared(size_t N, const remove_extent_t& u); // \tcode{T} is \tcode{U[]} template shared_ptr allocate_shared(const A& a, size_t N, - const remove_extent_t& u); // \tcode{T} is \tcode{U[]} + const remove_extent_t& u); // \tcode{T} is \tcode{U[]} template shared_ptr - make_shared(const remove_extent_t& u); // \tcode{T} is \tcode{U[N]} + make_shared(const remove_extent_t& u); // \tcode{T} is \tcode{U[N]} template - shared_ptr allocate_shared(const A& a, - const remove_extent_t& u); // \tcode{T} is \tcode{U[N]} + shared_ptr allocate_shared(const A& a, const remove_extent_t& u); // \tcode{T} is \tcode{U[N]} // \ref{util.smartptr.shared.cmp}, \tcode{shared_ptr} comparisons template From bbd5de278c6e7ae96d85bfa2582151f89adebd4e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thomas=20K=C3=B6ppe?= Date: Wed, 2 Aug 2017 16:51:00 +0100 Subject: [PATCH 07/79] [dcl.decl] Minor horizontal whitespace harmonization --- source/declarators.tex | 49 +++++++++++++++++++++--------------------- 1 file changed, 24 insertions(+), 25 deletions(-) diff --git a/source/declarators.tex b/source/declarators.tex index 1777be86bc..67dc02db77 100644 --- a/source/declarators.tex +++ b/source/declarators.tex @@ -3772,19 +3772,19 @@ Banana &&banana3 = Alaska(); // ill-formed } -const double& rcd2 = 2; // \tcode{rcd2} refers to temporary with value \tcode{2.0} -double&& rrd = 2; // \tcode{rrd} refers to temporary with value \tcode{2.0} +const double& rcd2 = 2; // \tcode{rcd2} refers to temporary with value \tcode{2.0} +double&& rrd = 2; // \tcode{rrd} refers to temporary with value \tcode{2.0} const volatile int cvi = 1; -const int& r2 = cvi; // error: cv-qualifier dropped +const int& r2 = cvi; // error: cv-qualifier dropped struct A { operator volatile int&(); } a; -const int& r3 = a; // error: cv-qualifier dropped - // from result of conversion function +const int& r3 = a; // error: cv-qualifier dropped + // from result of conversion function double d2 = 1.0; -double&& rrd2 = d2; // error: initializer is lvalue of related type +double&& rrd2 = d2; // error: initializer is lvalue of related type struct X { operator int&(); }; -int&& rri2 = X(); // error: result of conversion function is lvalue of related type +int&& rri2 = X(); // error: result of conversion function is lvalue of related type int i3 = 2; -double&& rrd3 = i3; // \tcode{rrd3} refers to temporary with value \tcode{2.0} +double&& rrd3 = i3; // \tcode{rrd3} refers to temporary with value \tcode{2.0} \end{codeblock} \end{example} \end{itemize} @@ -3880,8 +3880,8 @@ \begin{example} \begin{codeblock} struct A { int x; int y; int z; }; -A a{.y = 2, .x = 1}; // error: designator order does not match declaration order -A b{.x = 1, .z = 2}; // OK, \tcode{b.y} initialized to \tcode{0} +A a{.y = 2, .x = 1}; // error: designator order does not match declaration order +A b{.x = 1, .z = 2}; // OK, \tcode{b.y} initialized to \tcode{0} \end{codeblock} \end{example} @@ -4126,7 +4126,7 @@ struct A { std::initializer_list i4; - A() : i4{ 1, 2, 3 } {} // ill-formed, would create a dangling reference + A() : i4{ 1, 2, 3 } {} // ill-formed, would create a dangling reference }; \end{codeblock} @@ -4172,24 +4172,23 @@ list-initializations.\end{note} \begin{example} \begin{codeblock} -int x = 999; // \tcode{x} is not a constant expression +int x = 999; // \tcode{x} is not a constant expression const int y = 999; const int z = 99; -char c1 = x; // OK, though it might narrow (in this case, it does narrow) -char c2{x}; // error: might narrow -char c3{y}; // error: narrows (assuming \tcode{char} is 8 bits) -char c4{z}; // OK: no narrowing needed -unsigned char uc1 = {5}; // OK: no narrowing needed -unsigned char uc2 = {-1}; // error: narrows -unsigned int ui1 = {-1}; // error: narrows +char c1 = x; // OK, though it might narrow (in this case, it does narrow) +char c2{x}; // error: might narrow +char c3{y}; // error: narrows (assuming \tcode{char} is 8 bits) +char c4{z}; // OK: no narrowing needed +unsigned char uc1 = {5}; // OK: no narrowing needed +unsigned char uc2 = {-1}; // error: narrows +unsigned int ui1 = {-1}; // error: narrows signed int si1 = - { (unsigned int)-1 }; // error: narrows -int ii = {2.0}; // error: narrows -float f1 { x }; // error: might narrow -float f2 { 7 }; // OK: 7 can be exactly represented as a \tcode{float} + { (unsigned int)-1 }; // error: narrows +int ii = {2.0}; // error: narrows +float f1 { x }; // error: might narrow +float f2 { 7 }; // OK: 7 can be exactly represented as a \tcode{float} int f(int); -int a[] = - { 2, f(2), f(2.0) }; // OK: the \tcode{double}-to-\tcode{int} conversion is not at the top level +int a[] = { 2, f(2), f(2.0) }; // OK: the \tcode{double}-to-\tcode{int} conversion is not at the top level \end{codeblock} \end{example}% \indextext{initialization!list-initialization|)}% From c57ffb959dc939979111a4d1bcc31b71da643511 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thomas=20K=C3=B6ppe?= Date: Fri, 4 Aug 2017 18:33:41 +0100 Subject: [PATCH 08/79] [temp.deduct] Split long paragraph 8 --- source/templates.tex | 43 ++++++++++++++++++++++--------------------- 1 file changed, 22 insertions(+), 21 deletions(-) diff --git a/source/templates.tex b/source/templates.tex index 7de89d2069..eff4855db1 100644 --- a/source/templates.tex +++ b/source/templates.tex @@ -6853,16 +6853,13 @@ or obtained from default \grammarterm{template-argument}{s}. \begin{example} - \begin{codeblock} void f(Array& cv, Array& ci) { sort(cv); // calls \tcode{sort(Array\&)} sort(ci); // calls \tcode{sort(Array\&)} } \end{codeblock} - and - \begin{codeblock} void g(double d) { int i = convert(d); // calls \tcode{convert(double)} @@ -6878,7 +6875,6 @@ deduction fails. Specifically, the following steps are performed when evaluating an explicitly specified template argument list with respect to a given function template: - \begin{itemize} \item The specified template arguments must match the template parameters in kind (i.e., type, non-type, template). There @@ -6908,7 +6904,6 @@ variable within the function. \end{note} \begin{example} - \begin{codeblock} template void f(T t); template void g(const X x); @@ -6962,7 +6957,6 @@ } \end{codeblock} \end{example} - When all template arguments have been deduced or obtained from default template arguments, all uses of template parameters in the template parameter list of the template and the function type @@ -6989,10 +6983,13 @@ template arguments but also general expressions (i.e., non-constant expressions) inside \tcode{sizeof}, \tcode{decltype}, and other contexts that allow non-constant expressions. The substitution proceeds in lexical order and stops when -a condition that causes deduction to fail is encountered. \begin{note} The equivalent substitution in exception specifications is -done only when the \grammarterm{noexcept-specifier} is instantiated, at which point a program is ill-formed -if the substitution results in an invalid type or -expression. \end{note} +a condition that causes deduction to fail is encountered. +\begin{note} +The equivalent substitution in exception specifications is +done only when the \grammarterm{noexcept-specifier} is instantiated, +at which point a program is ill-formed +if the substitution results in an invalid type or expression. +\end{note} \begin{example} \begin{codeblock} template struct A { using X = typename T::X; }; @@ -7011,17 +7008,25 @@ \pnum If a substitution results in an invalid type or expression, type deduction fails. An invalid type or expression is one that would be ill-formed, with a diagnostic -required, if written using the substituted arguments. \begin{note} If no +required, if written using the substituted arguments. +\begin{note} +If no diagnostic is required, the program is still ill-formed. Access checking is done as part of the substitution -process. \end{note} Only invalid types and expressions in the immediate +process. +\end{note} +Only invalid types and expressions in the immediate context of the function type and its template parameter types can result in a deduction -failure. \begin{note} The substitution into types and expressions can result +failure. +\begin{note} +The substitution into types and expressions can result in effects such as the instantiation of class template specializations and/or function template specializations, the generation of implicitly-defined functions, etc. Such effects are not in the ``immediate context'' and can result in the -program being ill-formed.\end{note} +program being ill-formed. +\end{note} +\pnum \begin{example} \begin{codeblock} struct X { }; @@ -7036,9 +7041,9 @@ X x3 = f(x1, x2); // deduction fails on \#1 (cannot add \tcode{X+X}), calls \#2\end{codeblock} \end{example} -\begin{note} Type deduction may fail for -the following reasons: - +\pnum +\begin{note} +Type deduction may fail for the following reasons: \begin{itemize} \item Attempting to instantiate a pack expansion containing multiple parameter packs of differing lengths. \item @@ -7046,7 +7051,6 @@ function type, a reference type, or an abstract class type, or attempting to create an array with a size that is zero or negative. \begin{example} - \begin{codeblock} template int f(T[5]); int I = f(0); @@ -7056,7 +7060,6 @@ \item Attempting to use a type that is not a class or enumeration type in a qualified name. \begin{example} - \begin{codeblock} template int f(typename T::B*); int i = f(0); @@ -7075,7 +7078,6 @@ the specified member is not a non-type where a non-type is required. \end{itemize} \begin{example} - \begin{codeblock} template struct X { }; template