From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25227 invoked by alias); 11 Dec 2002 15:26:02 -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 25211 invoked by uid 71); 11 Dec 2002 15:26:01 -0000 Date: Wed, 11 Dec 2002 07:26:00 -0000 Message-ID: <20021211152601.25210.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Wolfgang Bangerth Subject: Re: c++/8821: gcc 3.2 problem with overloaded inherited operator Reply-To: Wolfgang Bangerth X-SW-Source: 2002-12/txt/msg00631.txt.bz2 List-Id: The following reply was made to PR c++/8821; it has been noted by GNATS. From: Wolfgang Bangerth To: Nathan Sidwell Cc: andre@kiwisound.de, , Subject: Re: c++/8821: gcc 3.2 problem with overloaded inherited operator Date: Wed, 11 Dec 2002 09:19:58 -0600 (CST) > > how operators behave. That's the question here. I concede that the > > behavior is confusing. > First name lookup happens, once a name has been found, base classes > are not searched. > Then overload resolution happens > then accessibility is checked > > This happens consistently regardless of virtuality or operatorness I was confused, sorry. (I guess mainly be the existence of -Woverloaded-virtual, which suggests that virtual functions behave differently.) Volker already pointed out the right paragraph of the standard, and y'all are right, of course. Thanks for so bravely trying to enlighten me ;-) Wolfgang ------------------------------------------------------------------------- Wolfgang Bangerth email: bangerth@ticam.utexas.edu www: http://www.ticam.utexas.edu/~bangerth