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