Re: definition of "implicit" inline?

Re: definition of "implicit" inline?

[Robert Dewar]

> I already give the reasons at multiple occasions in this debate with
> the appropriate quotes.
> The reason is mostly historic (see "The Design and Evolution of C++",
> section "Run-Time Efficiency").
> When inlining was orginally introduced in C with Classes, the only
> syntax available was definition within the class declaration and
> inlining was considered only for member functions.  Later, the keyword
> "inline" was introduced to permit inlining request for functions not
> defined within a class.  There is no slight difference nor implication
> that one form is superior to the other in terms of request.

history is not normative!

Re: definition of "implicit" inline?

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| > I already give the reasons at multiple occasions in this debate with
| > the appropriate quotes.
| > The reason is mostly historic (see "The Design and Evolution of C++",
| > section "Run-Time Efficiency").
| > When inlining was orginally introduced in C with Classes, the only
| > syntax available was definition within the class declaration and
| > inlining was considered only for member functions.  Later, the keyword
| > "inline" was introduced to permit inlining request for functions not
| > defined within a class.  There is no slight difference nor implication
| > that one form is superior to the other in terms of request.
| 
| history is not normative!

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++.

-- Gaby

Re: definition of "implicit" inline?

[Marc Espie]

I think you're jumping on Gaby for the wrong reasons.
C++ has an `inline' concept.

Both syntactic forms, the one with the inline keyword, and the one
that declares the method within the class, are equivalent.

Now, what the compiler does with the corresponding code is something
else. As long as it behaves `as if' the function body had been substituted
in place, it is fine.

But making or implying a semantic distinction between both syntactic
forms is a bad idea, which is why Gaby is strongly against the name
`implicit inline' for a semantic distinction.

C++ is a large language. Even with an existing standard, it still has
an history. This history muddles things up. Heck, old versions of g++
muddle things up even more.  And new stuff in C99 won't help.

Trying to keep things as simple as they can be, as Gaby is doing, is
a good thing.

Or maybe you are shooting down C++ for its lack of precise semantics,
especially compared to Ada ? Well, you're definitely right there, but
that doesn't make Gaby wrong :)

Re: definition of "implicit" inline?

[Gabriel Dos Reis]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

| | > 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.  
| | 
| | But your quotes from the standard make it clear that no one is transmuting
| | anything here.
| 
| Yes, the is transmuting.  That of saying that there is an implicit
| inline and one that is explicit.

[ sorry I didn't finished my sentence ]

The transmuting is in trying to introduce a notion of implicit/explicit
inline and in saying that inline is for optimization and the compiler
knows better than the programmer.  Inline is meant to be "substitute
the function body".

-- Gaby

Re: definition of "implicit" inline?

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| So, the quotes from the standard make it clear that the explicit inline
| keyword is significant.

As significant as the notion of "inline function".  7.1.3/ is not
treated different.

| I have no idea how the standard could be read
| otherwise.
| 
| >   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.
| 
| Of course that's pretty meaningless given that all semantics is "as if". 
| Whenever the standard appears to demand a particular code sequence, 
| appearences are deceptive!

Only to someone that does not know why inlining is introduced in C++.

| > 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.  
| 
| But your quotes from the standard make it clear that no one is transmuting
| anything here.

Yes, the is transmuting.  That of saying that there is an implicit
inline and one that is explicit.

-- Gaby

Re: definition of "implicit" inline?

[Robert Dewar]

So, the quotes from the standard make it clear that the explicit inline
keyword is significant. I have no idea how the standard could be read
otherwise.

>   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.

Of course that's pretty meaningless given that all semantics is "as if". 
Whenever the standard appears to demand a particular code sequence, 
appearences are deceptive!

> 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.  

But your quotes from the standard make it clear that no one is transmuting
anything here.

Re: definition of "implicit" inline?

[Gabriel Dos Reis]

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

Re: definition of "implicit" inline?

[Robert Dewar]

> 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. There is an ISO standard for C++. The meaning of C++
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 (in both C++ and Ada, there is absolutely no difference here, you are
imagining a difference, after all Ada is older than C++ from a standards
point of view :-) to take normal usage into account.

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.

Why? Because clearly just from the input on the list, there is no such
consensus. You can't make a consensus by shouting louder.

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.

Re: definition of "implicit" inline?

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| > Let's keep it simple and straight.  The example you gave is just that
| > of an inline function, not implicit inline function.  There is nothing
| > implicit about it.  It is an alternate syntax for defining an inline
| > function.  Not a syntax for defining an implicit inline function.
| 
| I find this exegesis confusing and self serving.

No it is not exegis not confusing neither self servin, unless you don't 
know C++. 

| It seems quite fine to
| refer to the form without inline has being implicitly inlined. Whether the
| two forms should or should not be treated differently is another matter.

In C++, they are no different.  

| One might ask *why* are there two forms. Perhaps someone should quote the
| exact language from the standard here.

I already give the reasons at multiple occasions in this debate with
the appropriate quotes.
The reason is mostly historic (see "The Design and Evolution of C++",
section "Run-Time Efficiency").
When inlining was orginally introduced in C with Classes, the only
syntax available was definition within the class declaration and
inlining was considered only for member functions.  Later, the keyword
"inline" was introduced to permit inlining request for functions not
defined within a class.  There is no slight difference nor implication
that one form is superior to the other in terms of request.

-- Gaby

Re: definition of "implicit" inline?

[Robert Dewar]

> Let's keep it simple and straight.  The example you gave is just that
> of an inline function, not implicit inline function.  There is nothing
> implicit about it.  It is an alternate syntax for defining an inline
> function.  Not a syntax for defining an implicit inline function.

I find this exegesis confusing and self serving. It seems quite fine to
refer to the form without inline has being implicitly inlined. Whether the
two forms should or should not be treated differently is another matter.

One might ask *why* are there two forms. Perhaps someone should quote the
exact language from the standard here.

Re: definition of "implicit" inline?

[Andreas Schwab]

Martin Reinecke <martin@MPA-Garching.MPG.DE> writes:

|> Hi,
|> 
|> there seems to be a lot of confusion concerning the term
|> "implicit inline". Maybe it would remove some misunderstandings
|> if everyone would state clearly what he means by this term.
|> 
|> In C++, the expression
|> 
|>    long a;
|> 
|> is equivalent to
|> 
|>    long int a;
|> 
|> This behavior is called "implicit int".

In C, the term "implicit int" is only used for cases where the type is
completely left out, like return type of a function definition (and this
syntax has been removed in C99).  The "long" vs "long int" case is just a
different spelling for the same thing.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: definition of "implicit" inline?

[Gabriel Dos Reis]

Martin Reinecke <martin@MPA-Garching.MPG.DE> writes:

| Hi,
| 
| there seems to be a lot of confusion concerning the term
| "implicit inline". Maybe it would remove some misunderstandings
| if everyone would state clearly what he means by this term.
| 
| In C++, the expression
| 
|    long a;
| 
| is equivalent to
| 
|    long int a;
| 
| This behavior is called "implicit int".
| 
| If I'm not greatly mistaken, the code
| 
| class foo {
|    void bar() { ...}
|    };
| 
| is also equivalent to (i.e. should be treated by the compiler
| in the same way as)
| 
| class foo {
|    inline void bar() { ...}
|    };
| 
| (see, e.g. Struostrup, 3rd ed, chapter 10.2.9)
| 
| What's wrong about calling this behavior "implicit inline"? I'd
| argue it practically begs for that name.

Because 

  1) it is the original syntax for "inline" -- as I already explained.

  2) It confused people into thinking that the inline is not requested 
     -- we already have evidence for such confusion, and this by some
       midlle end people, and that IS very alarming.
     I think we're better off just avoid that term for that situation
     because it means different thing for different people.  And we
     already have a name for that -- just "inline" -- why invent a new
     one that end to confuse people?  See "The Design and Evolution of C++",
    section "Run-Time Efficiency".

  3) implicit inline seems to mean different thing for middle end
     people who think that it means "I don't care".


Let's keep it simple and straight.  The example you gave is just that
of an inline function, not implicit inline function.  There is nothing
implicit about it.  It is an alternate syntax for defining an inline
function.  Not a syntax for defining an implicit inline function.

-- Gaby

definition of "implicit" inline?

[Martin Reinecke]

Hi,

there seems to be a lot of confusion concerning the term
"implicit inline". Maybe it would remove some misunderstandings
if everyone would state clearly what he means by this term.

In C++, the expression

   long a;

is equivalent to

   long int a;

This behavior is called "implicit int".

If I'm not greatly mistaken, the code

class foo {
   void bar() { ...}
   };

is also equivalent to (i.e. should be treated by the compiler
in the same way as)

class foo {
   inline void bar() { ...}
   };

(see, e.g. Struostrup, 3rd ed, chapter 10.2.9)

What's wrong about calling this behavior "implicit inline"? I'd
argue it practically begs for that name.

What's your take on this?

Thanks,
   Martin