From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7790 invoked by alias); 30 Jul 2003 13:41:36 -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 7743 invoked from network); 30 Jul 2003 13:41:35 -0000 Received: from unknown (HELO uniton.integrable-solutions.net) (62.212.99.186) by sources.redhat.com with SMTP; 30 Jul 2003 13:41:35 -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 h6UDfISu021649; Wed, 30 Jul 2003 15:41:18 +0200 Received: (from gdr@localhost) by uniton.integrable-solutions.net (8.12.3/8.12.3/Submit) id h6UDfHLq021648; Wed, 30 Jul 2003 15:41:17 +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> From: Gabriel Dos Reis In-Reply-To: <3F27C5DE.2010604@mpa-garching.mpg.de> Organization: Integrable Solutions Date: Wed, 30 Jul 2003 13:53:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-07/txt/msg02156.txt.bz2 Martin Reinecke writes: | Gabriel Dos Reis wrote: | > Martin Reinecke writes: | > | This is certainly a valid point of view, but I think that C++, as | > it exists | > | at the moment, just _doesn't give_ the programmer the possibility of specifying | > | what exactly (s)he wants. | > But taking out the only lever the programmer currently has is even | > far | > worse. | | Right, but that's exactly the dilemma with C++'s "implicit" inline: | if you want the compiler to _be able_ to inline a function, you should put | it in the class definition. Please note that there is no "implicit" inline in C++. The only thing that is present is that function definition within a class declaration is an inline definition, because that is the orginal syntax before inlining nonmember function was implemented. A function defined within a class is as inline as a function defined with the "inline" keyword outside a class. | But this implies an "inline" directive | which would more or less _force_ the compiler to always inline the code. | So, if inline was as strict as you'd like to see it, there would be no | way to tell gcc "here's a function that might be probably worthwhile to | inline". I could only say "inline this" or "don't inline". | | This could change if gcc starts to inline functions across translation units, | but currently it doesn't (I believe). That "worthwhile inlining" could subject to higher optimiations ("-O3") if it is so that we've reached the level of sophistication where automatic inline supersedes traditional "inline". But I see on concrete real world codes that the "inline" meaning transmutation GCC operates does cause more grief that it does good. | > | I think it is not generally possible for a programmer to decide | > | whether a function should be inlined or not (see below). | > I reckon that there are conner cases that "inline" does not cover. | > But, I'm worrying about the common situations -- and those that ave | > been subject of PRs. | | I've encountered the example I gave a few times in real-life code, | but in the frame of standard C++ nothing can be done about it, so | I cannot file a PR. | | > However, in lieu of pragmas, I will point out that current C++ | > gives the programmer means to express, in many corner cases, the | > intention of not inlining, by combining inline and noninline | > definitions and object functions. | | 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. -- Gaby