Стандарт C++ 11 (1119564), страница 84
Текст из файла (страница 84)
For direct-initialization, thoseexplicit conversion functions that are not hidden within S and yield type T or a type that can beconverted to type T with a qualification conversion (4.4) are also candidate functions. Conversionfunctions that return a cv-qualified type are considered to yield the cv-unqualified version of that typefor this process of selecting candidate functions. Conversion functions that return “reference to cv2X” return lvalues or xvalues, depending on the type of reference, of type “cv2 X” and are thereforeconsidered to yield X for this process of selecting candidate functions.2The argument list has one argument, which is the initializer expression.
[ Note: This argument will becompared against the implicit object parameter of the conversion functions. — end note ]13.3.1.61Initialization by conversion function for direct reference binding[over.match.ref ]Under the conditions specified in 8.5.3, a reference can be bound directly to a glvalue or class prvalue that isthe result of applying a conversion function to an initializer expression. Overload resolution is used to selectthe conversion function to be invoked. Assuming that “cv1 T” is the underlying type of the reference beinginitialized, and “cv S” is the type of the initializer expression, with S a class type, the candidate functionsare selected as follows:— The conversion functions of S and its base classes are considered, except that for copy-initialization,only the non-explicit conversion functions are considered. Those that are not hidden within S and yieldtype “lvalue reference to cv2 T2” (when 8.5.3 requires an lvalue result) or “cv2 T2” or “rvalue referenceto cv2 T2” (when 8.5.3 requires an rvalue result), where “cv1 T” is reference-compatible (8.5.3) with“cv2 T2”, are candidate functions.2The argument list has one argument, which is the initializer expression.
[ Note: This argument will becompared against the implicit object parameter of the conversion functions. — end note ]13.3.1.71Initialization by list-initialization[over.match.list]When objects of non-aggregate class type T are list-initialized (8.5.4), overload resolution selects the constructor in two phases:— Initially, the candidate functions are the initializer-list constructors (8.5.4) of the class T and theargument list consists of the initializer list as a single argument.— If no viable initializer-list constructor is found, overload resolution is performed again, where thecandidate functions are all the constructors of the class T and the argument list consists of the elementsof the initializer list.If the initializer list has no elements and T has a default constructor, the first phase is omitted.
In copy-listinitialization, if an explicit constructor is chosen, the initialization is ill-formed. [ Note: This differs fromother situations (13.3.1.3, 13.3.1.4), 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 ]13.3.21Viable functions[over.match.viable]From the set of candidate functions constructed for a given context (13.3.1), a set of viable functions ischosen, from which the best function will be selected by comparing argument conversion sequences for thebest fit (13.3.3).
The selection of viable functions considers relationships between arguments and functionparameters other than the ranking of conversion sequences.§ 13.3.2300© ISO/IEC 2011 – All rights reservedISO/IEC 14882:2011(E)2First, to be a viable function, a candidate function shall have enough parameters to agree in number withthe arguments in the list.— If there are m arguments in the list, all candidate functions having exactly m parameters are viable.— A candidate function having fewer than m parameters is viable only if it has an ellipsis in its parameterlist (8.3.5). For the purposes of overload resolution, any argument for which there is no correspondingparameter is considered to “match the ellipsis” (13.3.3.1.3) .— A candidate function having more than m parameters is viable only if the (m+1)-st parameter has adefault argument (8.3.6).131 For the purposes of overload resolution, the parameter list is truncatedon the right, so that there are exactly m parameters.3Second, for F to be a viable function, there shall exist for each argument an implicit conversion sequence (13.3.3.1) that converts that argument to the corresponding parameter of F.
If the parameter hasreference type, the implicit conversion sequence includes the operation of binding the reference, and the factthat an lvalue reference to non-const cannot be bound to an rvalue and that an rvalue reference cannot bebound to an lvalue can affect the viability of the function (see 13.3.3.1.4).13.3.31Best viable function[over.match.best]Define ICSi(F) as follows:— if F is a static member function, ICS1(F) is defined such that ICS1(F) is neither better nor worse thanICS1(G) for any function G, and, symmetrically, ICS1(G) is neither better nor worse than ICS1(F)132 ;otherwise,— let ICSi(F) denote the implicit conversion sequence that converts the i-th argument in the list to thetype of the i-th parameter of viable function F.
13.3.3.1 defines the implicit conversion sequences and13.3.3.2 defines what it means for one implicit conversion sequence to be a better conversion sequenceor worse conversion sequence than another.Given these definitions, a viable function F1 is defined to be a better function than another viable functionF2 if for all arguments i, ICSi(F1) is not a worse conversion sequence than ICSi(F2), and then— for some argument j, ICSj(F1) is a better conversion sequence than ICSj(F2), or, if not that,— the context is an initialization by user-defined conversion (see 8.5, 13.3.1.5, and 13.3.1.6) and thestandard conversion sequence from the return type of F1 to the destination type (i.e., the type of theentity being initialized) is a better conversion sequence than the standard conversion sequence fromthe return type of F2 to the destination type.
[ Example:struct A {A();operator int();operator double();} a;int i = a;float x = a;//////////a.operator int() followed by no conversionis better than a.operator double() followed bya conversion to intambiguous: both possibilities require conversions,and neither is better than the other131) According to 8.3.6, parameters following the (m+1)-st parameter must also have default arguments.132) If a function is a static member function, this definition means that the first argument, the implied object argument, hasno effect in the determination of whether the function is better or worse than any other function.§ 13.3.3© ISO/IEC 2011 – All rights reserved301ISO/IEC 14882:2011(E)— end example ] or, if not that,— F1 is a non-template function and F2 is a function template specialization, or, if not that,— F1 and F2 are function template specializations, and the function template for F1 is more specializedthan the template for F2 according to the partial ordering rules described in 14.5.6.2.2If there is exactly one viable function that is a better function than all other viable functions, then it is theone selected by overload resolution; otherwise the call is ill-formed133 .[ Example:void Fcn(const int*,void Fcn(int*, int);short);int i;short s = 0;void f() {Fcn(&i, s);// is ambiguous because// &i → int* is better than &i → const int*// but s → short is also better than s → intFcn(&i, 1L);// calls Fcn(int*, int), because// &i → int* is better than &i → const int*// and 1L → short and 1L → int are indistinguishableFcn(&i,’c’);// calls Fcn(int*, int), because// &i → int* is better than &i → const int*// and c → int is better than c → short}— end example ]3If the best viable function resolves to a function for which multiple declarations were found, and if at leasttwo of these declarations — or the declarations they refer to in the case of using-declarations — specify adefault argument that made the function viable, the program is ill-formed.
[ Example: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);f();}// OK, default argument was not used for viability// Error: found default argument twice133) The algorithm for selecting the best viable function is linear in the number of viable functions. Run a simple tournamentto find a function W that is not worse than any opponent it faced. Although another function F that W did not face might beat least as good as W, F cannot be the best function because at some point in the tournament F encountered another functionG such that F was not better than G. Hence, W is either the best function or there is no best function. So, make a second passover the viable functions to verify that W is better than all other functions.§ 13.3.3302© ISO/IEC 2011 – All rights reservedISO/IEC 14882:2011(E)— end example ]13.3.3.1Implicit conversion sequences[over.best.ics]1An implicit conversion sequence is a sequence of conversions used to convert an argument in a function callto the type of the corresponding parameter of the function being called.
The sequence of conversions is animplicit conversion as defined in Clause 4, which means it is governed by the rules for initialization of anobject or reference by a single expression (8.5, 8.5.3).2Implicit conversion sequences are concerned only with the type, cv-qualification, and value category of theargument and how these are converted to match the corresponding properties of the parameter. Otherproperties, such as the lifetime, storage class, alignment, or accessibility of the argument and whether or notthe argument is a bit-field are ignored. So, although an implicit conversion sequence can be defined for agiven argument-parameter pair, the conversion from the argument to the parameter might still be ill-formedin the final analysis.3A well-formed implicit conversion sequence is one of the following forms:— a standard conversion sequence (13.3.3.1.1),— a user-defined conversion sequence (13.3.3.1.2), or— an ellipsis conversion sequence (13.3.3.1.3).4However, when considering the argument of a constructor or user-defined conversion function that is acandidate by 13.3.1.3 when invoked for the copying/moving of the temporary in the second step of a classcopy-initialization, by 13.3.1.7 when passing the initializer list as a single argument or when the initializerlist has exactly one element and a conversion to some class X or reference to (possibly cv-qualified) X isconsidered for the first parameter of a constructor of X, or by 13.3.1.4, 13.3.1.5, or 13.3.1.6 in all cases, onlystandard conversion sequences and ellipsis conversion sequences are considered.5For the case where the parameter type is a reference, see 13.3.3.1.4.6When the parameter type is not a reference, the implicit conversion sequence models a copy-initialization ofthe parameter from the argument expression.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
