From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24448 invoked by alias); 3 Mar 2004 03:53:57 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 24441 invoked from network); 3 Mar 2004 03:53:57 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 3 Mar 2004 03:53:57 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i233rsb12580; Tue, 2 Mar 2004 22:53:54 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i233rs818462; Tue, 2 Mar 2004 22:53:54 -0500 Received: from livre.redhat.lsd.ic.unicamp.br (vpn26-2.sfbay.redhat.com [172.16.26.2]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id i233rqJ5006678; Tue, 2 Mar 2004 22:53:53 -0500 Received: from livre.redhat.lsd.ic.unicamp.br (livre.redhat.lsd.ic.unicamp.br [127.0.0.1]) by livre.redhat.lsd.ic.unicamp.br (8.12.11/8.12.11) with ESMTP id i233rpbB030030; Wed, 3 Mar 2004 00:53:51 -0300 Received: (from aoliva@localhost) by livre.redhat.lsd.ic.unicamp.br (8.12.11/8.12.11/Submit) id i233riuH029670; Wed, 3 Mar 2004 00:53:44 -0300 To: Gabriel Dos Reis Cc: Daniel Berlin , Kevin Atkinson , Mark Mielke , , Jeff Sturm , Nathan Sidwell Subject: Re: RFC: New C++ Attribute: final References: From: Alexandre Oliva Organization: Red Hat Global Engineering Services Compiler Team Date: Wed, 03 Mar 2004 03:53:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-03/txt/msg00200.txt.bz2 On Mar 2, 2004, Gabriel Dos Reis wrote: > Alexandre Oliva writes: > | Sure, but that's besides the point. In the case at hand, the object > | *may* have a derived type that overrides the member function, but the > | other member function actually wanted the non-overridden function to > | be called. > Like a local class? ;-) Err... I don't think so. Consider: struct base { typedef /* whatever */ iterator; iterator begin(); iterator end(); virtual void f(iterator); }; struct foo : base { void f(iterator) { do_something(); } void g() { call_func_for_each(this, & __extension__ __attribute__((__final__)) foo::f, begin(), end()); } }; struct derived : foo { void f(iterator); }; The idea is to not have derived::f called by call_func_for_each, but rather foo::f, even if g() is called for an object of type derived. I don't quite see how this relates with local classes. > Yes, but we need to (1) audit how good we already are at issue the > "final" semantics implied current situations (we're near zero) It can't possibly help the case above. The case above calls for a different semantics, that isn't provided by GCC. It's not a matter of getting the compiler clever enough to optimize away the dynamic call: in C++ the call *must* be dynamic if the dynamic type overrides foo::f(iterator). But in the case I propose, it would be possible to specify that dynamic binding is not to be done in the computed pointer to member. > And we're shouting for a new keyword. Before you call me a rigid guru, Have I? I don't think so. I just pointed out yet another case that could benefit from a final keyword, but used in a different context than that most people think of for the keyword final. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}