From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24280 invoked by alias); 30 Jul 2003 14:51:19 -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 24273 invoked from network); 30 Jul 2003 14:51:18 -0000 Received: from unknown (HELO uniton.integrable-solutions.net) (62.212.99.186) by sources.redhat.com with SMTP; 30 Jul 2003 14:51:18 -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 h6UEp1Su022066; Wed, 30 Jul 2003 16:51:01 +0200 Received: (from gdr@localhost) by uniton.integrable-solutions.net (8.12.3/8.12.3/Submit) id h6UEp1kg022065; Wed, 30 Jul 2003 16:51:01 +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> <3F27D7D9.5050705@mpa-garching.mpg.de> From: Gabriel Dos Reis In-Reply-To: <3F27D7D9.5050705@mpa-garching.mpg.de> Organization: Integrable Solutions Date: Wed, 30 Jul 2003 15:42:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-07/txt/msg02193.txt.bz2 Martin Reinecke writes: | Gabriel Dos Reis wrote: | | > The standard does mandate that the definition of an inline function | > be available in every translation unit that uses it. | | Thanks for the clarification. But I think there is still no way to expose | the definition of a not-explicitely-inline function to all | translation units where it is used. Yes. I do not see those as pressing as getting inlining of those declared inline good. | The fundamental problem is that there are three classes of functions: | - functions that should always be inlined | - functions where the compiler should decide | - functions that should never be inlined I can agree with that categorization. | The first category must have its definition in a header file. | The second category should have its definition in a header file also, | to give the compiler a chance of inlining it. But C++ won't let us, | because all functions with their definition in a header automatically | belong to the first category. Not actually. Not just because a function definition is put in a header file -- or more accurately, is avalaible in translation unit means that inlining is requested for that function. (I may suggest "mutable inline" for the second category and ~inline for the third :-) | Something seems fundamentally wrong here, and I think it is C++'s property | to automatically put the "inline" tag on all functions defined in a class | body, even if they don't have the "inline" keyword. But I see no chance | to get this changed. That is the way inlining is introduced in C++. Fundamentally, I think that decision is not wrong. | Maybe the discussion is so intense because there is no real solution? I'm confident that we can read a useful point, if we're careful enough not to turn it into a flame war -- we're not going to take the habit of turning every discussion about "inline" into a flame war, right? :-) -- Gaby