Re: operator+ overload resolution
From: Andrey Tarasevich (andreytarasevich_at_hotmail.com)
Date: 07/09/04
- Previous message: DaveC: "Network Protocol?"
- In reply to: Mark : "Re: operator+ overload resolution"
- Next in thread: Rob Williscroft: "Re: operator+ overload resolution"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 09 Jul 2004 00:16:33 -0700
Mark wrote:
>>
>>According to 13.3.1.2/3, the set of member candidates in this case is
>>created by qualified lookup for 'C2::operator+'. But this lookup will
>>not find the inherited 'C1::operator+' in 'C2' simply because it is
>>hidden in 'C2'. I.e. 'C1::operator+' is not even considered as a viable
>>function. For this reason there's no ambiguity.
>>
>>The potential for ambiguity will appear if you add a 'using' declaration
>>of 'C1::operator+' to 'C2's definition
>>
>> using C1::operator+;
>>
>>In this case 'C1::operator+' will be found by name lookup and added to
>>the set of viable functions. Calling this function will require two
>>implicit conversions of 'reference binding' type (see 13.3.3.1.4): one
>>for the implied object argument and another for the explicit argument of
>>'C1::operator+'. Both bind a 'C1&' to an object of 'C2' type. To me it
>>looks like it should result in an ambiguity. Such bindings are given the
>>'Conversion' rank, which means that 'C1::operator+' requires worse
>>conversion sequence for the implied object argument than 'C2::operator+'
>>(which requires no conversion). At the same time 'C2::operator+'
>>requires worse conversion sequence (user-defined) for the explicit
>>argument than 'C1::operator+'.
>>
> My standard is not currently is not within arm's reach, nonetheless
> I'm not sure if I'm following the meaning behind 'worse conversion
> sequence' for the implied and the explict object.
>
> For C2 worse than C1 (the explicit argument), the fact that the OP
> only defined operator+ with an int parameter, required a casts of o2
> to an int to perform the addition. Yes/No? If yes, how's C2 worse
> than C1?
'C2::operator+' is worse than 'C1::operator+' because in case of
'C2::operator+' a conversion from explicit argument type 'C2' to
explicit parameter type 'int' is required. This can only be done by a
user-defined conversion in this case.
In case of 'C1::operator+' another conversion is required: from explicit
argument type 'C2' to explicit parameter type 'C1&'. As far as I
understand the standard, this conversion is treated as a standard one
(even though it is not included in the list of "official" standard
conversions). For this reason 'C1::operator+' is "better" than
'C2::operator+' (standard conversions are always "better" than
user-defined ones).
> For C1 worse than C2, perhaps I'm misunderstanding the meaning of
> 'implied object argument'. Elaborate if you will.
Candidate member functions of class 'T' are considered to have an extra
parameter referred to as 'implied object parameter'. This parameter has
type 'T&' (or 'const/volatile T&' for const/volatile member functions).
This parameter is bound to the object, for which the member function has
been invoked. (That's what I referred to as 'implied object argument'.
Not a good choice of words. The argument is not really 'implied'. I
should've called it simply 'object argument'). Conversions that are
required in order to bind this parameter are also taken into account by
overload resolution. Once again, if I understood the standard correctly,
in this case the implied object parameter for 'C1::operator+' has type
'C1&' and the object has type 'C2', i.e. a conversion from 'C2' to 'C1&'
is required (ranked as 'Conversion'). The implied object parameter for
'C2::operator+' has type 'C2&' and and the object has type 'C2', i.e. no
conversion is required (ranked as 'Exact match'). That's why
'C2::operator+' is "better" from this point of view ('Exact
match'-ranked conversions are always "better" than 'Conversion'-ranked
ones).
It possible that the above explanation contains some mistakes caused by
my misunderstanding of some portions of the standard. Comeau's behavior
also suggests that. It would be great to get to the bottom of this issue.
-- Best regards, Andrey Tarasevich
- Previous message: DaveC: "Network Protocol?"
- In reply to: Mark : "Re: operator+ overload resolution"
- Next in thread: Rob Williscroft: "Re: operator+ overload resolution"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
