From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30171 invoked by alias); 3 Mar 2004 00:52:22 -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 30132 invoked from network); 3 Mar 2004 00:52:21 -0000 Received: from unknown (HELO uniton.integrable-solutions.net) (62.212.99.186) by sources.redhat.com with SMTP; 3 Mar 2004 00:52:21 -0000 Received: from uniton.integrable-solutions.net (localhost [127.0.0.1]) by uniton.integrable-solutions.net (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id i230gg9b008901; Wed, 3 Mar 2004 01:42:43 +0100 Received: (from gdr@localhost) by uniton.integrable-solutions.net (8.12.3/8.12.3/Submit) id i230ggIF008900; Wed, 3 Mar 2004 01:42:42 +0100 X-Authentication-Warning: uniton.integrable-solutions.net: gdr set sender to gdr@integrable-solutions.net using -f To: Alexandre Oliva Cc: Jeff Sturm , Nathan Sidwell , Kevin Atkinson , Mark Mielke , Subject: Re: RFC: New C++ Attribute: final References: From: Gabriel Dos Reis In-Reply-To: Organization: Integrable Solutions Date: Wed, 03 Mar 2004 00:52:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-03/txt/msg00194.txt.bz2 Alexandre Oliva writes: | On Mar 2, 2004, Gabriel Dos Reis wrote: | | > Taking a pointer-to-member is a very *general* mechanism, that comes | > with its price. And in pratice, it is far more efficient (whether the | > member function is virtual or not is immaterial) just to use custom | > function objects that directly call the function: You get far *better* | > efficiency. | | But then you can't use a generic template class to implement this | object, which makes it far more cumbersome. The function is certainly not generic, so what is the problem? | > When you create a pointer to member function, the member | > function does not need to be virtual | | Certainly not. But if such a pointer to member was final and bound to But, the pointer to member is a *constant*, in a given scope with defined lifetime. That GCC does not take advantage of that is another problem. | a known function, GCC might be able to short-curcuit function calls | through it, and even inline them. But we already have concrete situations with all the implied semantics constraints and yet GCC fails to to do proper job. Local class. I'm not saying final is bad, I'm merely pointing out that facts. | But since, for a virtual function, | it is not possible to know the exact function that is going to be | called unless you happen to know the dynamic type of the object, you | lose. With final, you'd win. | | > People keep damaging codes -- in the name of whatever (usually, | > generality). I believe people who damage their codes get what they | > deserve :-) | | > With the help of final or not, people are going to damage their codes | > anyway :-) | | So what do you propose? Education :-) | Not to use C++? You don't need C++; it is just a useful tool :-) You can write useful software in other programming languages; you can damage codes in other programming languages too. | Not to use any programming language? :-) :-) Stroustrup has an interesting chapter on "what programming at all?" in his third edition :-) Don't try to put in me in the camp of the "anti-final"s ;-/ -- Gaby