Стандарт C++ 98 (1119566), страница 62
Текст из файла (страница 62)
The sequence of conversions isan implicit 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 lvalue-ness of theargument and how these are converted to match the corresponding properties of the parameter. Other properties, such as the lifetime, storage class, alignment, or accessibility of the argument and whether or not theargument is a bit-field are ignored.
So, although an implicit conversion sequence can be defined for a givenargument-parameter pair, the conversion from the argument to the parameter might still be ill-formed in thefinal analysis.3Except in the context of an initialization by user-defined conversion (13.3.1.4, 13.3.1.5), a well-formedimplicit 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).4In the context of an initialization by user-defined conversion (i.e., when considering the argument of auser-defined conversion function; see 13.3.1.4, 13.3.1.5), only standard conversion sequences and ellipsisconversion sequences are allowed.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-initializationof the parameter from the argument expression.
The implicit conversion sequence is the one required toconvert the argument expression to an rvalue of the type of the parameter. [Note: when the parameter has aclass type, this is a conceptual conversion defined for the purposes of clause 13; the actual initialization isdefined in terms of constructors and is not a conversion. ] Any difference in top-level cv-qualification issubsumed by the initialization itself and does not constitute a conversion. [Example: a parameter of type Acan be initialized from an argument of type const A. The implicit conversion sequence for that case isthe identity sequence; it contains no “conversion” from const A to A.
] When the parameter has a classtype and the argument expression has the same type, the implicit conversion sequence is an identity221ISO/IEC 14882:1998(E)© ISO/IEC13.3.3.1 Implicit conversion sequences13 Overloadingconversion. When the parameter has a class type and the argument expression has a derived class type, theimplicit conversion sequence is a derived-to-base Conversion from the derived class to the base class.[Note: there is no such standard conversion; this derived-to-base Conversion exists only in the descriptionof implicit conversion sequences. ] A derived-to-base Conversion has Conversion rank (13.3.3.1.1).7In all contexts, when converting to the implicit object parameter or when converting to the left operand ofan assignment operation only standard conversion sequences that create no temporary object for the resultare allowed.8If no conversions are required to match an argument to a parameter type, the implicit conversion sequenceis the standard conversion sequence consisting of the identity conversion (13.3.3.1.1).9If no sequence of conversions can be found to convert an argument to a parameter type or the conversion isotherwise ill-formed, an implicit conversion sequence cannot be formed.10If several different sequences of conversions exist that each convert the argument to the parameter type, theimplicit conversion sequence associated with the parameter is defined to be the unique conversion sequencedesignated the ambiguous conversion sequence.
For the purpose of ranking implicit conversion sequencesas described in 13.3.3.2, the ambiguous conversion sequence is treated as a user-defined sequence that isindistinguishable from any other user-defined conversion sequence124). 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.11The three forms of implicit conversion sequences mentioned above are defined in the following subclauses.13.3.3.1.1 Standard conversion sequences[over.ics.scs]1Table 9 summarizes the conversions defined in clause 4 and partitions them into four disjoint categories:Lvalue Transformation, Qualification Adjustment, Promotion, and Conversion.
[Note: these categories areorthogonal with respect to lvalue-ness, cv-qualification, and data representation: the Lvalue Transformations do not change the cv-qualification or data representation of the type; the Qualification Adjustments donot change the lvalue-ness or data representation of the type; and the Promotions and Conversions do notchange the lvalue-ness or cv-qualification of the type. ]2[Note: As described in clause 4, 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. At most oneconversion from each category is allowed in a single standard conversion sequence.
If there are two ormore conversions in the sequence, the conversions are applied in the canonical order: LvalueTransformation, Promotion or Conversion, Qualification Adjustment. —end note]__________________124) The ambiguous conversion sequence is ranked with user-defined conversion sequences because multiple conversion sequences foran argument can exist only if they involve different user-defined conversions.
The ambiguous conversion sequence is indistinguishablefrom any other user-defined conversion sequence because it represents at least two user-defined conversion sequences, each with a different user-defined conversion, and any other user-defined conversion sequence must be indistinguishable from at least one of them.This rule prevents a function from becoming non-viable because of an ambiguous conversion sequence for one of its parameters. Consider this example,class B;class A {class B {class C {void f(A)void f(C)B b;f(b);A (B&); };operator A (); };C (B&); };{ }{ }// ambiguous because b -> C via constructor and// b → A via constructor or conversion function.If it were not for this rule, f(A) would be eliminated as a viable function for the call f(b) causing overload resolution to select f(C)as the function to call even though it is not clearly the best choice.
On the other hand, if an f(B) were to be declared then f(b)would resolve to that f(B) because the exact match with f(B) is better than any of the sequences required to match f(A).222© ISO/IECISO/IEC 14882:1998(E)13 Overloading313.3.3.1.1 Standard conversion sequencesEach conversion in Table 9 also has an associated rank (Exact Match, Promotion, or Conversion). Theseare used to rank standard conversion sequences (13.3.3.2). 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(13.3.3.1.4). If any of those has Conversion rank, the sequence has Conversion rank; otherwise, if any ofthose has Promotion rank, the sequence has Promotion rank; otherwise, the sequence has Exact Match rank.Table 9—conversions_______________________________________________________________________________________________________________________________________________________ Subclause ConversionCategoryRank_____________________________________________________________________________No conversions requiredIdentity_______________________________________________________________Lvalue-to-rvalue conversion4.1________________________________________ Lvalue Transformation Exact Match Array-to-pointer conversion4.2_______________________________________________________________________________________________________Function-to-pointer conversion 4.3 Qualification conversions Qualification Adjustment 4.4____________________________________________________________________________Integral promotions4.5 Promotion ________________________________________Promotion____________________________________________________________________________Floating point promotion4.6Integral conversions4.7________________________________________Floating point conversions4.8________________________________________ Floating-integral conversions 4.9____________________________Conversion Conversion ____________Pointer conversions4.10____________________________________________________________________Pointer to member conversions4.11____________Boolean conversions4.12____________________________________________________________________________13.3.3.1.2 User-defined conversion sequences[over.ics.user]1A user-defined conversion sequence consists of an initial standard conversion sequence followed by auser-defined conversion (12.3) followed by a second standard conversion sequence.
If the user-definedconversion is specified by a constructor (12.3.1), the initial standard conversion sequence converts thesource type to the type required by the argument of the constructor. If the user-defined conversion is specified by a conversion function (12.3.2), the initial standard conversion sequence converts the source type tothe implicit object parameter of the conversion function.2The second standard conversion sequence converts the result of the user-defined conversion to the targettype for the sequence. Since an implicit conversion sequence is an initialization, the special rules forinitialization by user-defined conversion apply when selecting the best user-defined conversion for a userdefined conversion sequence (see 13.3.3 and 13.3.3.1).3If the user-defined conversion is specified by a template conversion function, the second standard conversion sequence must have exact match rank.4A 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 factthat a copy constructor (i.e., a user-defined conversion function) is called for those cases.13.3.3.1.3 Ellipsis conversion sequences1[over.ics.ellipsis]An ellipsis conversion sequence occurs when an argument in a function call is matched with the ellipsisparameter specification of the function called.223ISO/IEC 14882:1998(E)© ISO/IEC13.3.3.1.4 Reference binding13 Overloading13.3.3.1.4 Reference binding1[over.ics.ref]When a parameter of reference type binds directly (8.5.3) to an argument expression, the implicit conversion sequence is the identity conversion, unless the argument expression has a type that is a derived class ofthe parameter type, in which case the implicit conversion sequence is a derived-to-base Conversion(13.3.3.1).