From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12190 invoked by alias); 4 Nov 2002 16:15:09 -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 12133 invoked by uid 61); 4 Nov 2002 16:15:08 -0000 Date: Mon, 04 Nov 2002 08:15:00 -0000 Message-ID: <20021104161508.12132.qmail@sources.redhat.com> To: gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, zyzstar@ibl.sk From: bangerth@dealii.org Reply-To: bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, zyzstar@ibl.sk, gcc-gnats@gcc.gnu.org Subject: Re: c++/8171: pointers to member functions comparison X-SW-Source: 2002-11/txt/msg00161.txt.bz2 List-Id: Synopsis: pointers to member functions comparison State-Changed-From-To: open->analyzed State-Changed-By: bangerth State-Changed-When: Mon Nov 4 08:15:06 2002 State-Changed-Why: I agree. In particular, the referenced part of the standard states: Pointer to member conversions(_conv.mem_) and qualification conversions (_conv.qual_) are performed to bring them to a common type. This does not seem to happen. (Conversion by hand yields the desired result though, so there is a way to work around this problem.) W. PS: As a sidenote (for the curious), the standard also says this on comparing pointers to member functions: if either [operand] is a pointer to a virtual member func- tion, the result is unspecified That seems like a trap you don't want to fall into... (And there isn't even a way for the compiler to warn you about.) http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8171