<div dir="ltr">I somehow missed your reply Richard. Is the bug report I showed earlier the same thing? And should we close it if it is?</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 23, 2014 at 7:45 AM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On Thu, May 22, 2014 at 1:12 AM, <span dir="ltr"><<a href="mailto:antoni@buszta.info" target="_blank">antoni@buszta.info</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi all,<br>
<br>
I have some small problem with clang behavior in such code:<br>
<br>
struct stream<br>
{<br>
stream() {}<br>
template<typename T><br>
inline stream& operator<<(T& t)<br>
{<br>
return *this;<br>
}<br>
};<br>
<br>
template<typename Stream><br>
inline Stream& operator<<(Stream& stream, int& t)<br>
{<br>
return stream;<br>
}<br>
<br>
int main(int argc, char *argv[])<br>
{<br>
int i = 42;<br>
stream a;<br>
a << i;<br>
<br>
return 0;<br>
}<br>
<br>
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:<br>
<br>
/home/abuszta/Development/<u></u>llvm/bin/clang++ -std=c++11 operator.cpp -o operator<br>
operator.cpp:21:7: error: use of overloaded operator '<<' is ambiguous (with operand types 'stream' and 'int')<br>
a << i;<br>
~ ^ ~<br>
operator.cpp:5:20: note: candidate function [with T = int]<br>
inline stream& operator<<(T& t)<br>
^<br>
operator.cpp:12:16: note: candidate function [with Stream = stream]<br>
inline Stream& operator<<(Stream& stream, int& t)<br>
^<br>
1 error generated.<br></blockquote><div><br></div></div></div><div>See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#532" target="_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#532</a><br>
</div><div><br>
</div><div>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:</div>
<div><br></div><div>stream &(stream &, T &) // member</div><div>Stream &(Stream &, int &) // non-member</div><div><br></div><div>These are unordered, so the call is ambiguous.</div><div><br></div>
<div>
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.</div>
<div><br></div><div>Apparently GCC doesn't implement DR532 in any mode.</div><div class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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...<br>
<br>
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.<br>
<br>
What is your interpretation of this behavior? Should I report bug?</blockquote><div><br></div></div><div>This is a GCC bug. And possibly a bug in Clang's C++98 mode, depending on your point of view.</div></div></div>
</div>
<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div>