This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: c++/8279: REGRESSION: failure to find a matching function in
- From: Joe Buck <jbuck at synopsys dot com>
- To: bangerth at ticam dot utexas dot edu (Wolfgang Bangerth)
- Cc: gcc-bugs at gcc dot gnu dot org, gcc-gnats at gcc dot gnu dot org, Joe dot Buck at synopsys dot COM, paolo at gcc dot gnu dot org
- Date: Mon, 21 Oct 2002 09:13:49 -0700 (PDT)
- Subject: 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.