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

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

[Joe Buck]

The following reply was made to PR c++/8279; it has been noted by GNATS.

From: Joe Buck <jbuck@synopsys.com>
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<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.

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

[Wolfgang Bangerth]

The following reply was made to PR c++/8279; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: jbuck@synopsys.com, <gcc-bugs@gcc.gnu.org>, <gcc-gnats@gcc.gnu.org>,
   <paolo@gcc.gnu.org>
Cc:  
Subject: Re: c++/8279: REGRESSION: failure to find a matching function in
Date: Mon, 21 Oct 2002 16:09:39 -0500 (CDT)

 > Even if gcc's behavior is correct, the diagnostic is puzzling:
 >
 > PREFIX/include/c++/3.2.1/bits/stream_iterator.h:141: no 
 >    match for `std::basic_ostream<char, std::char_traits<char> >& << const 
 >    std::pair<std::string, unsigned int>&' operator
 >
 > when there is what appears to be an exact match.  Strategies to come up
 > with a better diagnostic (e.g. tell the user why the function s/he
 > intended to use isn't accepted) would be wlcome.
 
 Maybe a first simple step would be to change the message to say
       no match for `...' found during name lookup
 Indicating that there _might_ even be such a name, but that it just was 
 not found. This would at least give a clue as to what may be going wrong.
 
 Regards
   Wolfgang
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:           bangerth@ticam.utexas.edu
                                www: http://www.ticam.utexas.edu/~bangerth
 
 

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

[Joe Buck]

The following reply was made to PR c++/8279; it has been noted by GNATS.

From: Joe Buck <jbuck@synopsys.com>
To: pcarlini@unitus.it (Paolo Carlini)
Cc: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, Joe.Buck@synopsys.COM,
   gcc-bugs@gcc.gnu.org, paolo@gcc.gnu.org
Subject: Re: c++/8279: REGRESSION: failure to find a matching function in
Date: Mon, 21 Oct 2002 12:37:49 -0700 (PDT)

 Paolo writes:
 
 > I'm tempted to agree with Wolfgang...
 
 While I still want to see the input from the comp.std.c++ folks, I've
 reduced the priority of this PR to non-critical/medium, since it's
 arguable that this not be considered a regression (even though the
 program worked in 2.95.x) due to the honor-std issues, and because there
 is a workaround.
 
 Even if gcc's behavior is correct, the diagnostic is puzzling:
 
 PREFIX/include/c++/3.2.1/bits/stream_iterator.h:141: no 
    match for `std::basic_ostream<char, std::char_traits<char> >& << const 
    std::pair<std::string, unsigned int>&' operator
 
 when there is what appears to be an exact match.  Strategies to come up
 with a better diagnostic (e.g. tell the user why the function s/he
 intended to use isn't accepted) would be wlcome.

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

[Wolfgang Bangerth]

The following reply was made to PR c++/8279; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Joe Buck <jbuck@synopsys.com>
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 11:35:26 -0500 (CDT)

 > > 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.
 
 As you say it, I'm indeed unsure about this: are symbols in the global 
 namespace _always_ visible? Or does the compiler only look into the 
 _present_ namespace and those introduced via Koenig lookup? I thought it 
 was the latter...
 
 
 > 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, 
 
 Or, more generally: if a function is defined in a namespace and all its 
 arguments are in a different namespace. Which unfortunately is not too 
 uncommon:
 
   void parse_string (const std::string &)
 
 Too bad :-(
 
 
 > The notion that users should casually go about extending the std namespace
 > feels wrong to me.  Is that really the intent?
 
 I don't think so.
 
 > > 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.
 
 Note in this context that there is already a defect report regarding 
 similar things. I don't exactly recall what it was about, but the problem 
 was something like the above: specifying whether overloading in the global 
 namespace (or a user namespace) may change function calls in the library.
 Maybe its DR 102 I had in mind 
 (http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_closed.html#102), it even 
 has an example almost exactly like yours. The conclusion given there is
   Rationale (10/99): This appears to be mainly a program design issue. 
   Furthermore, any attempt to address it in the core language would be 
   beyond the scope of what can be done in a Technical Corrigendum.
 
 Regards
   Wolfgang
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:           bangerth@ticam.utexas.edu
                                www: http://www.ticam.utexas.edu/~bangerth