From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17589 invoked by alias); 31 Jul 2003 11:31:59 -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 17582 invoked from network); 31 Jul 2003 11:31:58 -0000 Received: from unknown (HELO uniton.integrable-solutions.net) (62.212.99.186) by sources.redhat.com with SMTP; 31 Jul 2003 11:31:58 -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 h6VBVbSu028982; Thu, 31 Jul 2003 13:31:38 +0200 Received: (from gdr@localhost) by uniton.integrable-solutions.net (8.12.3/8.12.3/Submit) id h6VBVbhP028981; Thu, 31 Jul 2003 13:31:37 +0200 X-Authentication-Warning: uniton.integrable-solutions.net: gdr set sender to gdr@integrable-solutions.net using -f To: dewar@gnat.com (Robert Dewar) Cc: gcc@gcc.gnu.org, martin@MPA-Garching.MPG.DE Subject: Re: definition of "implicit" inline? References: <20030731110801.1CDCAF2E19@nile.gnat.com> From: Gabriel Dos Reis In-Reply-To: <20030731110801.1CDCAF2E19@nile.gnat.com> Organization: Integrable Solutions Date: Thu, 31 Jul 2003 13:37:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-07/txt/msg02303.txt.bz2 dewar@gnat.com (Robert Dewar) writes: | > Certainly, but you asked for the reason -why- we had two syntaxes to | > say the same thing in the first place. That is the reason. | > I think that anyone who seriously wants to argue about C++ should | > read its history and especially "The Design and Evolution of C++" or | > else he would miss the most important points and do bogus claims. | > That, probably, is a key difference between Ada and C++. | | No, you miss my point. you specifically asked: One might ask *why* are there two forms. The reasons I gave are the *why*. | There is an ISO standard for C++. The meaning of C++ Note that I answered your *why*. | is entirely contained within this history *WITHOUT* any reference to history. | That's the fundamental meaning of an ISO standard. | | So from a formal point of view, an implementor need look only at the ISO | standard. Now, in cases where the standard does not prescribe things, it is | fine The ISO C++ standard says 7.1.2/2 A function declaration (8.3.5, 9.3, 11.4) with an inline specifier declares an inline function. The inline specifier indicates to the implementation that inline substitution of the function body at the point of call is to be preferred to the usual function call mechanism. An implementation is not required to perform this inline substitution at the point of call; however, even if this inline substitution is omitted, the other rules for inline functions defined by 7.1.2 shall still be respected. 7.1.2/3 A function defined within a class definition is an inline function. The inline specifier shall not appear on a block scope function declaration. 7.1.2/4 An inline function shall be defined in every translation unit in which it is used and shall have exactly the same definition in every case (3.2). [Note: a call to the inline function may be encountered before its defi-nition appears in the translation unit. ] If a function with external linkage is declared inline in one transla-tion unit, it shall be declared inline in all translation units in which it appears; no diagnostic is required. An inline function with external linkage shall have the same address in all translation units. A static local variable in an extern inline function always refers to the same object. A string literal in an extern inline function is the same object in different translation units. | (in both C++ and Ada, there is absolutely no difference here, you are | imagining a difference, I'm not imagining any difference but I'm not assuminig there is no difference either. What I do know for sure is the wording of the C++ standard. In this case it says: The inline specifier indicates to the implementation that inline substitution of the function body at the point of call is to be preferred to the usual function call mechanism. It does not say "optimize", a notion you tried to introduce in an earlier. It says "substitute". When I, as a programmer, state my preference I would like the compiler to listen. | after all Ada is older than C++ from a standards | point of view :-) to take normal usage into account. Ada being older from standards point of view does not mean that C++ semantics ought ot follow Ada's, if that were your point. | But your (somewhat hysterical I must say) claims that all C++ programmers | behave in a certain way with regard to the use and expectations of inline | is clearly unsupportable. Most certainly a hysterical claim is that from someone who does not know the semantics of the language under consideration and who keepings on arguinig as if we were arguing about Ada. And in this case, it is not me. | Why? Because clearly just from the input on the list, there is no such | consensus. You can't make a consensus by shouting louder. There is no consensus, either, that the current logic is good. I'm not shouting louder. I'm just trying to get people to consider the *language* _under discussion_ and to prevent them from transmuting the intent of the keyword. | So there really seems a problem that, to a much greater extent than is the | case with Ada, the programmer's intentions are not so clear with respect to | inline. But we're not arguing for inline in Ada. We're disussing C++. -- Gaby