[cfe-dev] Templated operator overloading

[Nikola Smiljanic]

And what would be the best thing to do with temp.func.order\p3.cpp? Mark it
as expected-error and put a comment that we've extended DR532 to cover
C++98/03?


On Sat, May 24, 2014 at 6:50 AM, Richard Smith <richard at metafoo.co.uk>wrote:

> On Thu, May 22, 2014 at 4:37 PM, Nikola Smiljanic <popizdeh at gmail.com>wrote:
>
>> I somehow missed your reply Richard. Is the bug report I showed earlier
>> the same thing? And should we close it if it is?
>>
>
> Yes, that bug is the same thing. I think we should extend this behavior to
> C++98 mode, and then close the bug (if you're interested, look for
> CPlusPlus11 in SemaTemplateDeduction; this is the second and third
> occurrence).
>
>
>> On Fri, May 23, 2014 at 7:45 AM, Richard Smith <richard at metafoo.co.uk>wrote:
>>
>>> On Thu, May 22, 2014 at 1:12 AM, <antoni at buszta.info> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I have some small problem with clang behavior in such code:
>>>>
>>>> struct stream
>>>> {
>>>>     stream() {}
>>>>     template<typename T>
>>>>     inline stream& operator<<(T& t)
>>>>     {
>>>>         return *this;
>>>>     }
>>>> };
>>>>
>>>> template<typename Stream>
>>>> inline Stream& operator<<(Stream& stream, int& t)
>>>> {
>>>>     return stream;
>>>> }
>>>>
>>>> int main(int argc, char *argv[])
>>>> {
>>>>     int i = 42;
>>>>     stream a;
>>>>     a << i;
>>>>
>>>>     return 0;
>>>> }
>>>>
>>>> This code compiles fine under clang (I have checked with 3.4 and
>>>> current trunk) and gcc. However when I add -std=c++11 it still compiles
>>>> fine under gcc but it stops compiling under clang. Error is:
>>>>
>>>> /home/abuszta/Development/llvm/bin/clang++ -std=c++11    operator.cpp
>>>>   -o operator
>>>> operator.cpp:21:7: error: use of overloaded operator '<<' is ambiguous
>>>> (with operand types 'stream' and 'int')
>>>>     a << i;
>>>>     ~ ^  ~
>>>> operator.cpp:5:20: note: candidate function [with T = int]
>>>>     inline stream& operator<<(T& t)
>>>>                    ^
>>>> operator.cpp:12:16: note: candidate function [with Stream = stream]
>>>> inline Stream& operator<<(Stream& stream, int& t)
>>>>                ^
>>>> 1 error generated.
>>>>
>>>
>>> See http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#532
>>>
>>> Deduction succeeds for both function templates, and neither candidate is
>>> better than the other based on implicit conversion sequences, so we perform
>>> partial ordering on the function templates. Per 14.5.6.2, we perform
>>> partial ordering on these signatures:
>>>
>>> stream &(stream &, T &) // member
>>> Stream &(Stream &, int &) // non-member
>>>
>>> These are unordered, so the call is ambiguous.
>>>
>>>  In C++98 mode, we don't implement DR532, and instead only consider the
>>> second parameter. That's arguably misguided, since the wording prior to
>>> DR532 was simply broken (in particular, it didn't say that we ignore the
>>> first parameter from the non-member, which is what we do in C++98 mode),
>>> and we'd be better off using the C++11 rule rather than making up a
>>> different rule.
>>>
>>> Apparently GCC doesn't implement DR532 in any mode.
>>>
>>> In order to answer the question which behavior is good and which is bad
>>>> I tried to find appropriate section in C++ standard. After analyzing
>>>> 14.5.6.2 (section about Partial ordering of function templates in N3337)
>>>> and related I think there should not be any ambiguity after substitution
>>>> and function should be choosed...
>>>>
>>>> What is more, when I make const stream a; this code compiles fine even
>>>> with -std=c++11 and chooses the standalone function in favor to member
>>>> function which suggests that there may be some problem with template
>>>> resolution here.
>>>>
>>>> What is your interpretation of this behavior? Should I report bug?
>>>
>>>
>>> This is a GCC bug. And possibly a bug in Clang's C++98 mode, depending
>>> on your point of view.
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140526/bba34a78/attachment.html>