From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11321 invoked by alias); 30 Jul 2003 11:43:42 -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 11300 invoked from network); 30 Jul 2003 11:43:41 -0000 Received: from unknown (HELO uniton.integrable-solutions.net) (62.212.99.186) by sources.redhat.com with SMTP; 30 Jul 2003 11:43:41 -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 h6UBhOSu021073; Wed, 30 Jul 2003 13:43:24 +0200 Received: (from gdr@localhost) by uniton.integrable-solutions.net (8.12.3/8.12.3/Submit) id h6UBhO5Q021072; Wed, 30 Jul 2003 13:43:24 +0200 X-Authentication-Warning: uniton.integrable-solutions.net: gdr set sender to gdr@integrable-solutions.net using -f To: Alexandre Oliva Cc: Steven Bosscher , Richard Guenther , gcc@gcc.gnu.org Subject: Re: std::pow implementation References: <1059481647.3651.120.camel@steven.lr-s.tudelft.nl> <1059483328.3651.144.camel@steven.lr-s.tudelft.nl> <1059487859.3650.208.camel@steven.lr-s.tudelft.nl> From: Gabriel Dos Reis In-Reply-To: Organization: Integrable Solutions Date: Wed, 30 Jul 2003 12:20:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-07/txt/msg02130.txt.bz2 Alexandre Oliva writes: | On Jul 30, 2003, Gabriel Dos Reis wrote: | | > I gave a quote of the purpose of inline in C++. | | There is indeed one obvious use for inline, namely accessor | functions. There are several other uses that are not that obvious, in | which the programmer can't possibly tell whether it's profitable to Defining a function inline is not a careless action. If inlining isn't profitable, the programmer will profile et remove the inline definition. You don't know better than the programmer. [...] | You're arguing for a definition that was created 20 years ago, against I'm arguing for a definition that was created 20 yars ago, that still describes contemporary situations, and more importantly that is part of the language that was created more than 20 years ago and that is subject of this discussion. | one that was come up with after at least 15 years of accumulation of | experience on the subject, Yet, we're not at the level of sophistication that will make that definition obsolete. And the sade part of the history is that the evidences that motivated the introduction of "inline" are still contemporary. Please, don't transmute the meaning of "inline". | just because you see one case in which that | old definition *might* suit some particular coding style better than | the new definition, even though, if the new definition is implemented | correctly, it can't possibly produce worse code? And the implementation of the "new definition" has always been for the next version. Whereas the old definition did and does what it is designed for. When you'll reach the state of maturity that makes your "new definition" always better than the "old definition", then at time you may have legitimate reasons and evidences to make the transmutation. Not before. Right now, the only things the "new definition" offers is lock-in syntaxes. Please do give "inline" its original meaning. -- Gaby