From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26896 invoked by alias); 30 Jul 2003 14:21:44 -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 26868 invoked from network); 30 Jul 2003 14:21:43 -0000 Received: from unknown (HELO uniton.integrable-solutions.net) (62.212.99.186) by sources.redhat.com with SMTP; 30 Jul 2003 14:21:43 -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 h6UELPSu021901; Wed, 30 Jul 2003 16:21:26 +0200 Received: (from gdr@localhost) by uniton.integrable-solutions.net (8.12.3/8.12.3/Submit) id h6UELPGV021900; Wed, 30 Jul 2003 16:21:25 +0200 X-Authentication-Warning: uniton.integrable-solutions.net: gdr set sender to gdr@integrable-solutions.net using -f To: Martin Reinecke Cc: gcc@gcc.gnu.org Subject: Re: std::pow implementation References: <3F27BD38.8020009@mpa-garching.mpg.de> <3F27C5DE.2010604@mpa-garching.mpg.de> <3F27D07A.9070602@mpa-garching.mpg.de> From: Gabriel Dos Reis In-Reply-To: <3F27D07A.9070602@mpa-garching.mpg.de> Organization: Integrable Solutions Date: Wed, 30 Jul 2003 14:33:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-07/txt/msg02181.txt.bz2 Martin Reinecke writes: [...] | Say I write the following | | ==========foo.h | | class foo | { | inline void bar(); | }; | | ==========foo.cc | | inline void foo::bar() {...} | | No current g++ will inline foo::bar() (and most other compilers won't either) when I | call it from, say, baz.cc. The standard does mandate that the definition of an inline function be available in every translation unit that uses it. [...] | > But I see on concrete real world codes that the "inline" meaning | > transmutation GCC operates does cause more grief that it does good. | | Probably. I just think it was caused by the fact that C++ compilers | have been imperfect (i.e. lacking intermodule inlining) for a long time. KCC did better, even with no inter translation-unit optimization, on real world codes. | And because so many codes exist that were written with the "transmuted" | meaning in mind, there will be a terrible lot of breakage if the meaning | is reset abruptly. | | > | You're right. It's not too beautiful and makes maintenance a bit harder, | > | but on the other hand it shouldn't happen too often. | > and is expressed with standard constructs. | | Agreed. I was arguing for a possible extension of the standard itself, not | for introducing new pragmas. I see, but that tends to confuse the debate. -- Gaby