From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20013 invoked by alias); 21 Oct 2002 16:16:01 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 19986 invoked by uid 71); 21 Oct 2002 16:16:01 -0000 Date: Mon, 21 Oct 2002 09:16:00 -0000 Message-ID: <20021021161601.19984.qmail@sources.redhat.com> To: paolo@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Joe Buck Subject: Re: c++/8279: REGRESSION: failure to find a matching function in Reply-To: Joe Buck X-SW-Source: 2002-10/txt/msg00779.txt.bz2 List-Id: The following reply was made to PR c++/8279; it has been noted by GNATS. From: Joe Buck To: bangerth@ticam.utexas.edu (Wolfgang Bangerth) Cc: gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org, Joe.Buck@synopsys.COM, paolo@gcc.gnu.org Subject: Re: c++/8279: REGRESSION: failure to find a matching function in Date: Mon, 21 Oct 2002 09:13:49 -0700 (PDT) > 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&) { ... } 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.