This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: c++/8279: REGRESSION: failure to find a matching function in


> The testcase fails for a relatively simple reason: copying to an 
> ostream_iterator invokes ostream_iterator::operator=, which here looks 
> like this:
>       ostream_iterator& 
>       operator=(const _Tp& __value) 
>       { 
> 	*_M_stream << __value;
> 	//...
> 	return *this;
>       }
> _M_stream is of type std::ostream, and __value of type _Tp=std::pair. So 
> the compiler looks for an operator
>       std::ostream << std::pair
> 
> Since the declaration of this class is in namespace std, in looks for this 
> operator in namespace std. Since both types are in namespace std, Koenig 
> lookup also does not bring in additional namespaces. It will thus not find 
> the globally declared operator of the test case.

But wait a minute: bringing in additional namespaces would possibly make
additional symbols visible, but the global namespace is already visible.

Just the same, it's possible that you are correct.  But if you are
correct, then the compiler should probably issue warnings whenever someone
defines an operator in the global namespace that takes two arguments that
are both in the same non-global namespace, because that operator will not
be found in some contexts.

That is, if someone declares

std::ostream&
operator<<(std::ostream&, const std::pair<T,U>&) { ... }

for any T and U, the compiler should warn that this operator will not
be found in many contexts.

The notion that users should casually go about extending the std namespace
feels wrong to me.  Is that really the intent?

> At least, I believe the compiler is right to reject the code, and that 
> this is not a bug.

I will ask the folks at comp.std.c++ for an opinion.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]