C++ Logo

std-discussion

Advanced search

Re: Function overload resolution

From: Vladimir Grigoriev <vlad.moscow_at_[hidden]>
Date: Tue, 28 Sep 2021 08:15:59 +0300
I know that they are ambiguous. I have pointed out that it looks like a contradiction and unexpected behavior. It would be more natural if in the second case also the second function would be selected.
 
With best regards,
(Vlad from Moscow)
You can meet me at http://cpp.forum24.ru/ or www.stackoverflow.com or http://ru.stackoverflow.com
 
  
>Вторник, 28 сентября 2021, 5:39 +03:00 от jim x <xmh970252187_at_[hidden]>:
>
>
>Vladimir Grigoriev via Std-Discussion < std-discussion_at_[hidden] > 于2021年9月28日周二 上午12:23写道:
>>In my opinion there is some inconsistence in the function overload resolution when a function parameter has a referenced array type.
>>
>>Let assume that we have two functions
>>
>>void f( const ( &a )[] );
>>
>>and
>>
>>void f( const ( &a )[2] );
>>
>>If to write
>>
>>f( { 1, 2 } );
>>
>>then the second function will be selected.
>>
>>However if to write
>>
>>int a[2];
>>
>>and then
>>
>>f( a );
>>
>>then the compiler will issue an error relative to an ambiguity.
>>
>>It would be more natural if in this case also the second function would be selected.
>>
>>With best regards
>>(Vlad from Moscow)
>>
>>
>>
>>
>>You can meet me at http://cpp.forum24.ru/ or www.stackoverflow.com or http://ru.stackoverflow.com --
>>Std-Discussion mailing list
>>Std-Discussion_at_[hidden]
>>https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>
>
>For the first example, [over.ics.rank] p3 explicitly says that the second viable function is better than the first one
>>  Two implicit conversion sequences of the same form are indistinguishable conversion sequences unless one of the following rules applies:
>>> -[...]
>>>  L1  and  L2  convert to arrays of the same element type, and either the number of elements n 1 initialized by L1 is less than the number of elements n 2 initialized by L2 , or n 1 = n 2 and L2 converts to an array of unknown bound and L1 does not,
>
>
>For the second case, they are all governed by [dcl.init.ref#5.1] > If the reference is an lvalue reference and the initializer expression
>>> is an lvalue (but is not a bit-field), and “cv1 T1” is reference-compatible with “cv2 T2”, or
>*
>
>pointer to an array of unknown bound of const int is reference-compatible with a pointer to an array of 2 int (via qualification conversion). Regardless of `#1` or `#2`, they are identity conversion in reference binding as per [over.ics.ref] p1, and they cannot be distinguishable by [over.ics.rank] and [over.match.best.general], so they are ambiguous.
 

Received on 2021-09-28 00:16:10