From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4560 invoked by alias); 30 Jul 2003 14:04:50 -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 4401 invoked from network); 30 Jul 2003 14:04:43 -0000 Received: from unknown (HELO ibm-4.MPA-Garching.MPG.DE) (130.183.83.34) by sources.redhat.com with SMTP; 30 Jul 2003 14:04:43 -0000 Received: from mpa-garching.mpg.de (ncb-3.MPA-Garching.MPG.DE [130.183.84.13]) by ibm-4.MPA-Garching.MPG.DE (AIX4.3/8.9.3/8.9.1) with ESMTP id QAA44296 for ; Wed, 30 Jul 2003 16:04:42 +0200 Message-ID: <3F27D07A.9070602@mpa-garching.mpg.de> Date: Wed, 30 Jul 2003 14:14:00 -0000 From: Martin Reinecke Organization: Max-Planck-Institut fuer Astrophysik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: gcc@gcc.gnu.org Subject: Re: std::pow implementation References: <3F27BD38.8020009@mpa-garching.mpg.de> <3F27C5DE.2010604@mpa-garching.mpg.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-07/txt/msg02170.txt.bz2 Gabriel Dos Reis wrote: > 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. I know; this is why I put "implicit" in quotes. But this doesn't help, I think. 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. So there is a practical difference between defining a function in the class body, and declaring it as inline and defining it in a separate .cc file. If we assume for now that intermodule optimization is not done (and that's the current situation), there is no way to tell the C++ compiler "this function might be useful to inline", because it has to see the function body before it can decide whether to inline it or not. And it can't see it because it's in a different translation unit. AFAIK, it's ill-formed to write =========foo.h class foo { void bar(); }; void foo::bar() {...} =========end of foo.h I think this is only OK if I explicitly declare bar() as inline. If not, I run into trouble with the ODR. > | 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". I'll be happy with this as soon as intermodule optimization works well. Without it, we have not gained anything, as the example shows. > 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. 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. Martin