Стандарт C++ 98 (1119566), страница 61
Текст из файла (страница 61)
The candidate functions are all the constructors of the class of the object being initialized. The argument list is theexpression-list within the parentheses of the initializer.13.3.1.4 Copy-initialization of class by user-defined conversion1[over.match.ctor][over.match.copy]Under the conditions specified in 8.5, as part of a copy-initialization of an object of class type, a userdefined 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. Assuming that “cv1T” is the type of the object being initialized, with T a class type, the candidate functions are selected as follows:— The converting constructors (12.3.1) of T are candidate functions.— When the type of the initializer expression is a class type “cv S”, the conversion functions of S and itsbase classes are considered.
Those that are not hidden within S and yield a type whose cv-unqualifiedversion is the same type as T or is a derived class thereof are candidate functions. Conversion functionsthat return “reference to T” return lvalues of type T and are therefore considered to yield T for this process of selecting candidate functions.2In both cases, the argument list has one argument, which is the initializer expression. [Note: this argumentwill be compared against the first parameter of the constructors and against the implicit object parameter ofthe conversion functions.
]13.3.1.5 Initialization by conversion function1[over.match.conv]Under the conditions specified in 8.5, as part of an initialization of an object of nonclass type, a conversionfunction 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 “cv1T” is the type of the object being initialized, and “cv S” is the type of the initializer expression, with S aclass type, the candidate functions are selected as follows:— The conversion functions of S and its base classes are considered.
Those that are not hidden within Sand yield type T or a type that can be converted to type T via a standard conversion sequence__________________function. The process repeats until an operator-> function returns a value of non-class type.218© ISO/IEC13 OverloadingISO/IEC 14882:1998(E)13.3.1.5 Initialization by conversion function(13.3.3.1.1) are candidate functions. Conversion functions that return a cv-qualified type are consideredto yield the cv-unqualified version of that type for this process of selecting candidate functions. Conversion functions that return “reference to T” return lvalues of type T and are therefore considered toyield T for this process of selecting candidate functions.2The argument list has one argument, which is the initializer expression.
[Note: this argument will be compared against the implicit object parameter of the conversion functions. ]13.3.1.6 Initialization by conversion function for direct reference binding1[over.match.ref]Under the conditions specified in 8.5.3, a reference can be bound directly to an lvalue that is the result ofapplying a conversion function to an initializer expression. Overload resolution is used to select the conversion function to be invoked.
Assuming that “cv1 T” is the underlying type of the reference being initialized, and “cv S” is the type of the initializer expression, with S a class type, the candidate functions areselected as follows:— The conversion functions of S and its base classes are considered. Those that are not hidden within Sand yield type “reference to cv2 T2”, where “cv1 T” is reference-compatible (8.5.3) with “cv2 T2”, arecandidate functions.2The argument list has one argument, which is the initializer expression.
[Note: this argument will be compared against the implicit object parameter of the conversion functions. ]13.3.2 Viable functions[over.match.viable]1From the set of candidate functions constructed for a given context (13.3.1), a set of viable functions is chosen, 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.2First, to be a viable function, a candidate function shall have enough parameters to agree in number with thearguments 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).121) For the purposes of overload resolution, the parameter list is truncated onthe 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 has referencetype, the implicit conversion sequence includes the operation of binding the reference, and the fact that areference to non-const cannot be bound to an rvalue can affect the viability of the function (see13.3.3.1.4).13.3.3 Best Viable Function1[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)122);otherwise,__________________121) According to 8.3.6, parameters following the (m+1)– st parameter must also have default arguments.122) If a function is a static member function, this definition means that the first argument, the implied object parameter, has no effectin the determination of whether the function is better or worse than any other function.219ISO/IEC 14882:1998(E)13.3.3 Best Viable Function© ISO/IEC13 Overloading— let ICSi(F) denote the implicit conversion sequence that converts the i-th argument in the list to the typeof 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,— F1 is a non-template function and F2 is a template function specialization, or, if not that,— F1 and F2 are template functions, and the function template for F1 is more specialized than the template for F2 according to the partial ordering rules described in 14.5.5.2, or, if not that,— the context is an initialization by user-defined conversion (see 8.5, 13.3.1.5) and the standard conversion sequence from the return type of 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 F2to the destination type.
[Example:struct A {A();operator int();operator double();} a;int i = a;float x = a;// a.operator int() followed by no conversion// is better than a.operator double() followed by// a conversion to int// ambiguous: both possibilities require conversions,// and neither is better than the other—end example]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-formed123).__________________123) The algorithm for selecting the best viable function is linear in the number of viable functions.
Run a simple tournament to find afunction W that is not worse than any opponent it faced. Although another function F that W did not face might be at least as good as W,F cannot be the best function because at some point in the tournament F encountered another function G such that F was not better thanG. Hence, W is either the best function or there is no best function.
So, make a second pass over the viable functions to verify that W isbetter than all other functions.220© ISO/IECISO/IEC 14882:1998(E)13 Overloading313.3.3 Best Viable Function[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]13.3.3.1 Implicit conversion sequences[over.best.ics]1An implicit conversion sequence is a sequence of conversions used to convert an argument in a functioncall to the type of the corresponding parameter of the function being called.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
