From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-80071-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 23543 invoked by alias); 30 Jul 2003 07:21:05 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 23535 invoked from network); 30 Jul 2003 07:21:04 -0000
Received: from unknown (HELO uniton.integrable-solutions.net) (62.212.99.186)
  by sources.redhat.com with SMTP; 30 Jul 2003 07:21:04 -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 h6U7KmSu020272;
	Wed, 30 Jul 2003 09:20:48 +0200
Received: (from gdr@localhost)
	by uniton.integrable-solutions.net (8.12.3/8.12.3/Submit) id h6U7Klea020271;
	Wed, 30 Jul 2003 09:20:47 +0200
X-Authentication-Warning: uniton.integrable-solutions.net: gdr set sender to gdr@integrable-solutions.net using -f
To: Steven Bosscher <s.bosscher@student.tudelft.nl>
Cc: Alexandre Oliva <aoliva@redhat.com>,
   Richard Guenther <rguenth@tat.physik.uni-tuebingen.de>, gcc@gcc.gnu.org
Subject: Re: std::pow implementation
References: <Pine.LNX.4.44.0307291353040.14031-100000@bellatrix.tat.physik.uni-tuebingen.de>
	<m3he55tu7y.fsf@uniton.integrable-solutions.net>
	<1059481647.3651.120.camel@steven.lr-s.tudelft.nl>
	<m3wue1se52.fsf@uniton.integrable-solutions.net>
	<1059483328.3651.144.camel@steven.lr-s.tudelft.nl>
	<m34r15scu3.fsf@uniton.integrable-solutions.net>
	<1059487859.3650.208.camel@steven.lr-s.tudelft.nl>
	<m3ptjto1bh.fsf@uniton.integrable-solutions.net>
	<ord6fsbq09.fsf@free.redhat.lsd.ic.unicamp.br>
	<m3fzkofw5r.fsf@uniton.integrable-solutions.net>
	<oru194a8kw.fsf@free.redhat.lsd.ic.unicamp.br>
	<m3llugcydy.fsf@uniton.integrable-solutions.net>
	<1059548337.3642.4.camel@steven.lr-s.tudelft.nl>
From: Gabriel Dos Reis <gdr@integrable-solutions.net>
In-Reply-To: <1059548337.3642.4.camel@steven.lr-s.tudelft.nl>
Organization: Integrable Solutions
Date: Wed, 30 Jul 2003 11:31:00 -0000
Message-ID: <m38yqgcwfk.fsf@uniton.integrable-solutions.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-SW-Source: 2003-07/txt/msg02121.txt.bz2

Steven Bosscher <s.bosscher@student.tudelft.nl> writes:

| Op wo 30-07-2003, om 08:38 schreef Gabriel Dos Reis:
| > | > But, why don't you trust the programmer?  Why do you insist that you
| > | > know better than the programmer?
| > | 
| > | Because (1) inline is implicit in C++,
| > 
| > No, that is *your* invention.  Inline is NOT implicit.  That is just
| > an invention of people like you who prefer to ignore the purpose of
| > "inline".  Please, do give inline its original and obvious meaning. 
| 
| Hmm I really don't follow you.  If "inline" is not implicit, would that
| mean that for the (broken) example earlier in this thread:
| 
| class bla
| {
| public:
|   foo() {i=1;}
| private:
|   int i;
| }
| 
| a use of foo would _not_ be inlined because the user hasn't marked it
| inline???

The point you're missing is that only the *keyword* is implicit.  Not
the fact that the function is *actually* declared inline.  In really,
when inline was originally introduced in C++, the above syntax was the
only one available.  See my answer to Alexandre who raised the same
syntactical issue.

There is more than syntax about it.

-- Gaby