In article <KANZE.93Aug30202453@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
>In article <rfgCC9B35.xp@netcom.com> rfg@netcom.com (Ronald F.
>Guilmette) writes:
>
>|> In article <26324@alice.att.com> ark@alice.UUCP () writes:
>|> >In article <rfgCBtLK9.MzC@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>
>|> >> In particular, I would like to know what justification (if any) has been
>|> >> offered for distinguishing between inline member functions and inline non-
>|> >> member functions with respect to this kind of inter-translation unit
>|> >> trickyness.  Why should the two cases be handled any differently?
>|> >
>|> >Because the ARM says so.
>
>|> That explains nothing.
>
>|> What I was hoping was that there might be some humanly understandable
>|> *rationale* for why these rules were put into the ARM.  (I do tend to
>|> assume that there is at least some rationale for why the language is
>|> the way it is.  Do I assume too much?)
>
>I think that it is just pragmatic...

Well James, you're speculating.  I appreciate the effort, but i was looking
for something more definitive.

Let me put it another way.

As I recall, we found something the ARM which said something about inline
member function having to be essentially identical across multiple trans-
lation units, whereas no such stipulation is made regarding inline non-
member functions.  (Have I recalled this discussion correctly?)

I asked why this was so, and Andrew Koenig said it was because The Book
says it is so.

I then asked why The Book says it should be so, and I haven't yet gotten
any truly useful answer.

So let me be blunt about this... If there is no good reason for inline
member functions to be different from inline non-member functions (as I
suspect there isn't) then they should NOT be different (and I would suggest
to X3J16 that any passages of the current working paper which would sug-
gest that they ARE different should be expunged with extreme prejudice,
as no such differentiating rules serve any purpose other than to add
unnecessary complexity to an already sufficiently complex language).

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <26324@alice.att.com> ark@alice.UUCP () writes:
>In article <rfgCBtLK9.MzC@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>
>> In particular, I would like to know what justification (if any) has been
>> offered for distinguishing between inline member functions and inline non-
>> member functions with respect to this kind of inter-translation unit
>> trickyness.  Why should the two cases be handled any differently?
>
>Because the ARM says so.

That explains nothing.

What I was hoping was that there might be some humanly understandable
*rationale* for why these rules were put into the ARM.  (I do tend to
assume that there is at least some rationale for why the language is
the way it is.  Do I assume too much?)

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <rfgCC9B35.xp@netcom.com> rfg@netcom.com (Ronald F.
Guilmette) writes:

|> In article <26324@alice.att.com> ark@alice.UUCP () writes:
|> >In article <rfgCBtLK9.MzC@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:

|> >> In particular, I would like to know what justification (if any) has been
|> >> offered for distinguishing between inline member functions and inline non-
|> >> member functions with respect to this kind of inter-translation unit
|> >> trickyness.  Why should the two cases be handled any differently?
|> >
|> >Because the ARM says so.

|> That explains nothing.

|> What I was hoping was that there might be some humanly understandable
|> *rationale* for why these rules were put into the ARM.  (I do tend to
|> assume that there is at least some rationale for why the language is
|> the way it is.  Do I assume too much?)

I think that it is just pragmatic, and the fact that 'static' means
something different when applied to a member function than when
applied to a non-member function.

If the compiler actually does inline the function, then there will be
at least one copy in each module in which it is used.  This is (sort
of) what would happen if a non-member function were declared static.
So defaulting non-member functions to static seems somehow reasonable
(although not necessarily necessary).  On the other hand, a static
member function has different semantics (and not just linkage) than a
non-static one.  Defaulting to static here would be a pain for the
user, especially as there is no way to declare a member function
"un-static."
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

In article <Aug18.235432.29344@halcon.dpi.udec.cl>
llongeri@vangogh.die.udec.cl.die.udec.cl (Luis Longeri) writes:

|> Ronald F. Guilmette (rfg@netcom.com) wrote:
|> : In article <26309@alice.att.com> ark@alice.UUCP () writes:
|> : >In article <rfgCBrzsJ.FtK@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:

|> : >> I believe that what the ARM is REALLY trying to say is that if you have
|> : >> *any* inline function definition (e.g. in a header file) then you are
|> : >> not supposed to be playing games with the preprocessor which would make
|> : >> that definition appear to be in any way different to the different
|> : >> "includers".

|> : >We happened to talk about this issue a bit at the last standards meeting.
|> : >We tentatively concluded that the paragraph above is correct if you change
|> : >`inline function' to `inline member function,' but for ordinarily inline
|> : >functions,
|> : >
|> : > inline void f() { /* ... */ }
|> : >
|> : >is precisely equivalent to
|> : >
|> : > static inline void f() { /* ... */ }
|> : >
|> : >with no restrictions on f meaning different things in different translation
|> : >units.

|> : Thank you Andrew.

|> : If I may, allow me to draw you out about this a bit more.

|> : In particular, I would like to know what justification (if any) has been
|> : offered for distinguishing between inline member functions and inline non-
|> : member functions with respect to this kind of inter-translation unit
|> : trickyness.  Why should the two cases be handled any differently?  I
|> : can see no good reason for that.  Either *ALL* kinds of inline functions
|> : should be required to be essentially token-for-token identical (after
|> : preprocessing) in all translation units of a given program, or else
|> : *NONE* of the inline functions should be restricted by such a requirment.

|> : Why the dicotomy?

|> Hi, well. myself, I think that this is because inline nonmember functions can
|> always be expanded inline, and inline member functions can't always, because
|> they can be virtual functions, and it depends on runtime which virtual inline
|> member function to use.  It's that right?????

I think it is even more because member functions and non-member
functions *are* two different things.  The are defined differently,
called differently, have a different syntax to take their addresses
and a different syntax for pointers to them.

And the word static means something different when applied to them.
In particular, declaring that an inline member function is static
would *not* exempt it from the one definition rule; ie, it would *not*
mean that the function could have different definitions in different
translation units.  It would mean that the function could be called
without a this pointer, and could not access member variables.

All in all, I don't find the rules concerning linkage of inline
functions very elegant.  But I do find them pragmatically useful.
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

In article <CBw0xM.Cpq@noose.ecn.purdue.edu>, luj@ecn.purdue.edu (John Lu) writes:
...
|> What happens if an inline member function calls an inline nonmember funtion
|> (e.g. assert(int))  ?  Note the latter can have different definitions
|> in different translation units.

Though it would likely be undetectable, this should be a violation of the C++ language specifications. Conceivably (but not likely) the language could be amended to make it illegal for an inline member function to use anything local to a compilation unit.

This would be equivalent to having 2 program units define the same class differently.

In article <24qveh$700@fnnews.fnal.gov>, b91926@fnclub.fnal.gov (David Sachs) writes:
|> In article <CBw0xM.Cpq@noose.ecn.purdue.edu>, luj@ecn.purdue.edu (John Lu) writes:
|> ...
|> |> What happens if an inline member function calls an inline nonmember funtion
|> |> (e.g. assert(int))  ?  Note the latter can have different definitions
|> |> in different translation units.
|>
|> Though it would likely be undetectable, this should be a violation of
|> the C++ language specifications.

If inline nonmember functions are treated differently from inline memeber
functions, it inevitably leads to violation of the C++ language specification,
undetectable by current compiler technology. Even if such violations
can be detected by compilers with inter-tranlation unit information,
it is synatically and semantically ugly to ask user to care about
what functions to call inside inline member functions. This also violates
the principle of encapsulation.

In summary, inconsistent treatment of inline nonmember and memeber functions,
leads to inconsistent specification of the C++ language.


|> Conceivably (but not likely)
|> the language could be amended to make it illegal for an inline
|> member function to use anything local to a compilation unit.|>
|>
How to enforce it ? Not in the conceivalbly feasible in the near future
unless compilers disable any inline substitions.

How about amending the language so that inline member functions can
have different definitons in different tranlations units
but _logically_ same definition ?  This is similar to logical const-ness
and place the responsibility on programmers to ensure that inline member
function definitions in different translation units are logically
the same. This, for example, makes it possible for programmers to selectively
turn on/off debugging code in different translations units.

Comments ?

--
-- John Lu                              | INTERNET:luj@{ecn,cs}.purdue.edu --
-- Civil Engieering & Computer Sciences | UUCP:    {pur-ee, purdue}!luj    --
-- Purdue University                    | PHONE:   317-494-2234            --
-- West Lafayette, IN 47907-1208        | FAX:     317-496-1105            --

In article <24qveh$700@fnnews.fnal.gov>, b91926@fnclub.fnal.gov (David Sachs) writes:
|> In article <CBw0xM.Cpq@noose.ecn.purdue.edu>, luj@ecn.purdue.edu (John Lu) writes:
|> ...
|> |> What happens if an inline member function calls an inline nonmember funtion
|> |> (e.g. assert(int))  ?  Note the latter can have different definitions
|> |> in different translation units.
|>
|> Though it would likely be undetectable, this should be a violation of the C++ language specifications. Conceivably (but not likely) the language could be amended to make it illegal for an inline member function to use anything local to a compilation unit.|>
|>
|> This would be equivalent to having 2 program units define the same class
differently.

This is getting messy and, as far as I can see, for no reason.  We all have
an intuitive sense of what 'inline' means.  Now lets write the standard to
conform with this intuition:

1. All inline functions have internal linkage, whether members or
   non-members, explicitly declared inline or implicitly inlined by
   including the function body in a class.  This produces the simplest,
   most intuitive semantics and does not require adding another
   hard-to-enforce rule (that all definitions must match).

2. The internal linkage of inlines cannot be changed by the use of extern.
   I add this rule because the semantics of extern inline are difficult to
   describe and add very little to the language.

3. If there are different versions of a virtual inline funciton in
   different compilation units, the version that is used in any given
   context is implementation defined (or unspecified?).  I could have
   linked the version to the appearance of the constructor or something,
   but that seems like unnecessarily legislating behavior in the case of
   rather bad coding practice.

The worst part of the rules, as far as I can tell, is that I introduced the
concept of internal linkage to class members when the concept did not
really exist before.  Moreover, there is no explicit key word to introduce
this concept.  My next posting goes more into this problem with a possible
solution.

--

- Pablo

-------------------------------------------------------------------------
Pablo Halpern          Permanent: (508) 435-5274   phalpern@world.std.com
                       Thru 3/94: (508) 659-4639   pabloh@wal.hp.com
-------------------------------------------------------------------------

In article <CBw0xM.Cpq@noose.ecn.purdue.edu>, luj@ecn.purdue.edu (John Lu) writes:
...
|> What happens if an inline member function calls an inline nonmember funtion
|> (e.g. assert(int))  ?  Note the latter can have different definitions
|> in different translation units.

The problem here is related to the generall problem in C++ that 'static'
has several vastly different meanings.  What we don't have is a way of
using more than one meaning at a time.  What concerns us here is what I
will call "FileStatic," where a function or variable is given file-scope,
and "ClassStatic," where a function or variable is declared to belong to a
class instead of to instances of that class.  If two separate keywords were
used instead of just "static," we could write things like:

class A
{
  ClassStatic int a; // There exists only one "a" for this class
  ClassStatic int foo(); // Foo has no "this" pointer
  FileStatic int bar();  // Bar has a "this" pointer can be defined
    // differently (or is not defined) in different
    // compilation units
  FileStatic ClassStatic int baz(); // File-scope, no "this pointer"
  FileStatic ClassStatic int i = 5; // File-scope static belonging to class
};

Now, the standard could simply state that inline implies FileStatic and
that would solve most of the problem.  Still open, whether "extern" could
be used to undo this default definition.  I say no, because defining the
semantics of extern inline is unnecessarily complex, with very little
advantage to be gained.

So...  How do we introduce FileStatic into the inside of classes, where
"static" means "ClassStatic"?  Although not all of the above possibilities
can be expressed, the following rules would allow the most important cases:

1. All inline functions, both member and non-member, have internal linkage
   (FileStatic).  See my previous posting for more on this.

2. Any member variable which is declared static and which is initialized
   within the class definition has internal linkage.  Think of this as
   "inline variables."

Example:

class B
{
  int foo() { return 5; }         // internal linkage
  static int bar();               // class static (non-inline)
  static int baz() { return 6; }  // class static with internal linkage
  static int a;                   // class static
  static int b = 7;               // class static with internal linkage
  static const int size = 8;      // class static with internal linkage
  int array[size];                // This works!
};

Note that the definition of "size" is something people have been wanting to
be able to do for a long time.  This proposal makes it legal and gives it
meaning.

Is this too esoteric to bother proposing to the committee?

--

- Pablo

-------------------------------------------------------------------------
Pablo Halpern          Permanent: (508) 435-5274   phalpern@world.std.com
                       Thru 3/94: (508) 659-4639   pabloh@wal.hp.com
-------------------------------------------------------------------------

Ronald F. Guilmette (rfg@netcom.com) wrote:
: In article <26309@alice.att.com> ark@alice.UUCP () writes:
: >In article <rfgCBrzsJ.FtK@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
: >
: >> I believe that what the ARM is REALLY trying to say is that if you have
: >> *any* inline function definition (e.g. in a header file) then you are
: >> not supposed to be playing games with the preprocessor which would make
: >> that definition appear to be in any way different to the different
: >> "includers".
: >
: >We happened to talk about this issue a bit at the last standards meeting.
: >We tentatively concluded that the paragraph above is correct if you change
: >`inline function' to `inline member function,' but for ordinarily inline
: >functions,
: >
: > inline void f() { /* ... */ }
: >
: >is precisely equivalent to
: >
: > static inline void f() { /* ... */ }
: >
: >with no restrictions on f meaning different things in different translation
: >units.

: Thank you Andrew.

: If I may, allow me to draw you out about this a bit more.

: In particular, I would like to know what justification (if any) has been
: offered for distinguishing between inline member functions and inline non-
: member functions with respect to this kind of inter-translation unit
: trickyness.  Why should the two cases be handled any differently?  I
: can see no good reason for that.  Either *ALL* kinds of inline functions
: should be required to be essentially token-for-token identical (after
: preprocessing) in all translation units of a given program, or else
: *NONE* of the inline functions should be restricted by such a requirment.

: Why the dicotomy?

Hi, well. myself, I think that this is because inline nonmember functions can
always be expanded inline, and inline member functions can't always, because
they can be virtual functions, and it depends on runtime which virtual inline
member function to use.  It's that right?????


     Luis Longeri H.
     llongeri@vangogh.die.udec.cl

Pablo: In your intelligent message, I have to draw your attention to
this:

> class B
> {
>   [...]
>   static const int size = 8;      // class static with internal linkage
>   int array[size];                // This works!
> };
>
> Note that the definition of "size" is something people have been wanting to
> be able to do for a long time.  This proposal makes it legal and gives it
> meaning.

Try:

class B
{ enum  { size  = 8,  };
  int array[size];                // This already works
};

--
The Tom spreads its huge, scaly wings and soars into the sky...
(tob@world.std.com, TomBreton@delphi.com)

In article <KANZE.93Aug3184429@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
>In article <rfgCB22Hw.4F@netcom.com> rfg@netcom.com (Ronald F.
>Guilmette) writes:
>
>    [me, talking about inline member functions.]
>|> >The linkage is the same as the linkage of class C...
>
>|> Can you please provide supporting quotations from the ARM for this (alleged)
>|> rule?
>
>I think Ron is right.  I drew my opinions from general discussions I
>have had, but the actual words in the ARM (section 3.3) are:
>"Noninline class member functions have external linkage.  Inline class
>member functions must have exactly one definition in a program."
>
>Now I suspect that this is one place where the ARM doesn't really mean
>what it says.  Allowing only one definition of an inline member
>function is a program would break most existing code.

Not necessarily.  It all depends upon your definition of the term
"definition".

I believe that what the ARM is REALLY trying to say is that if you have
*any* inline function definition (e.g. in a header file) then you are
not supposed to be playing games with the preprocessor which would make
that definition appear to be in any way different to the different
"includers".

For example, this isn't allowed:

 include.h:
 -----------------------------------------------------------------
 inline int foo () { return VALUE; }
 -----------------------------------------------------------------

 file1.C:
 -----------------------------------------------------------------
 #include "include.h"

 #define VALUE 88

 int caller1 () { return foo (); }
 -----------------------------------------------------------------

 file2.C:
 -----------------------------------------------------------------
 #include "include.h"

 #define VALUE 99

 int caller2 () { return foo (); }
 -----------------------------------------------------------------

Now ask yourself this important question:  Given the above source files,
if the two .C files are compiled and then linked together into a single
program, how many "definitions" of `foo' are "in" the program?

Would your answer change if both of the .C files defined VALUE to the
exact same number?  (Would there then be only one "definition" of the
function `foo', or would it still be two definitions in two separate
translation units?)

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <rfgCBrzsJ.FtK@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:

> I believe that what the ARM is REALLY trying to say is that if you have
> *any* inline function definition (e.g. in a header file) then you are
> not supposed to be playing games with the preprocessor which would make
> that definition appear to be in any way different to the different
> "includers".

We happened to talk about this issue a bit at the last standards meeting.
We tentatively concluded that the paragraph above is correct if you change
`inline function' to `inline member function,' but for ordinarily inline
functions,

 inline void f() { /* ... */ }

is precisely equivalent to

 static inline void f() { /* ... */ }

with no restrictions on f meaning different things in different translation
units.  It's analogous to the way `const' implies `static' for variable
declarations.

This led to another question: what does it mean to say

 extern inline void f() { /* ... */ }

Here the discussion ran out of time without reaching a consensus.
Some people said `It's obvious: it should mean the same as

 void f() { /* ... */ }

except that the compiler is encouraged to expand it inline where it can.'
Others said `No: inline implies static, so it should mean the same as

 extern static void f() { /* ... */ }

which is clearly an error.'  Still others said `Well, the ARM isn't crystal
clear so this gives us an opportunity to clarify it.  What it *should*
mean is that there is a definition somewhere that doesn't say `inline;'
any other definitions that do say `inline' must match.  This lets the user
control on a translation unit basis where the function should be expanded
inline and where it shouldn't.

I imagine there will be more discussion at the next meeting.
--
    --Andrew Koenig
      ark@research.att.com

In article <26309@alice.att.com> ark@alice.UUCP () writes:
>In article <rfgCBrzsJ.FtK@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>
>> I believe that what the ARM is REALLY trying to say is that if you have
>> *any* inline function definition (e.g. in a header file) then you are
>> not supposed to be playing games with the preprocessor which would make
>> that definition appear to be in any way different to the different
>> "includers".
>
>We happened to talk about this issue a bit at the last standards meeting.
>We tentatively concluded that the paragraph above is correct if you change
>`inline function' to `inline member function,' but for ordinarily inline
>functions,
>
> inline void f() { /* ... */ }
>
>is precisely equivalent to
>
> static inline void f() { /* ... */ }
>
>with no restrictions on f meaning different things in different translation
>units.

Thank you Andrew.

If I may, allow me to draw you out about this a bit more.

In particular, I would like to know what justification (if any) has been
offered for distinguishing between inline member functions and inline non-
member functions with respect to this kind of inter-translation unit
trickyness.  Why should the two cases be handled any differently?  I
can see no good reason for that.  Either *ALL* kinds of inline functions
should be required to be essentially token-for-token identical (after
preprocessing) in all translation units of a given program, or else
*NONE* of the inline functions should be restricted by such a requirment.

Why the dicotomy?

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <rfgCBtLK9.MzC@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:

> In particular, I would like to know what justification (if any) has been
> offered for distinguishing between inline member functions and inline non-
> member functions with respect to this kind of inter-translation unit
> trickyness.  Why should the two cases be handled any differently?

Because the ARM says so.

7.1.2: The inline specifier is a hint to the compiler that inline
substitution of the function body is to be preferred to the usual
function call implementation.  The hint may be ignored.  For a
nonmember function [the] inline specifier also gives the function
default internal linkage.

9.3: Each member function that is called must have exactly one definition
in a program.

 Only an inline member function can be defined in several translation
 units, and even then it is illegal to provide different definitions
 in different translation units.
--
    --Andrew Koenig
      ark@research.att.com

In article <26324@alice.att.com>, ark@alice.att.com (Andrew Koenig) writes:
|>
|> Because the ARM says so.
|>
|> 7.1.2: The inline specifier is a hint to the compiler that inline
|> substitution of the function body is to be preferred to the usual
|> function call implementation.  The hint may be ignored.  For a
|> nonmember function [the] inline specifier also gives the function
|> default internal linkage.
|>
|> 9.3: Each member function that is called must have exactly one definition
|> in a program.
|>
|>  Only an inline member function can be defined in several translation
|>  units, and even then it is illegal to provide different definitions
|>  in different translation units.

What happens if an inline member function calls an inline nonmember funtion
(e.g. assert(int))  ?  Note the latter can have different definitions
in different translation units.

Regards,

--
-- John Lu                              | INTERNET:luj@{ecn,cs}.purdue.edu --
-- Civil Engieering & Computer Sciences | UUCP:    {pur-ee, purdue}!luj    --
-- Purdue University                    | PHONE:   317-494-2234            --
-- West Lafayette, IN 47907-1208        | FAX:     317-496-1105            --

In article <rfgCB22Hw.4F@netcom.com> rfg@netcom.com (Ronald F.
Guilmette) writes:

    [me, talking about inline member functions.]
|> >The linkage is the same as the linkage of class C...

|> Can you please provide supporting quotations from the ARM for this (alleged)
|> rule?

I think Ron is right.  I drew my opinions from general discussions I
have had, but the actual words in the ARM (section 3.3) are:
"Noninline class member functions have external linkage.  Inline class
member functions must have exactly one definition in a program."

Now I suspect that this is one place where the ARM doesn't really mean
what it says.  Allowing only one definition of an inline member
function is a program would break most existing code.  But this is
also the exact wording in the current version of the draft working
papers, so until the standards committee actual does something, it
says what it says, and not what (I think) it meant to say.  (As if
there weren't enough problems already.)

What I think it meant to say (or should say) is that inline class
member functions have the same linkage as the class.  (This is
actually what it says about the noninline class member functions,
since the presence of a noninline class member function makes the
class itself have external linkage.)  In addition, I think that what
was meant was not that the function must have exactly one definition,
but that if the function has external linkage, all of the definitions
be indentical.  This seems to be what most compilers implement today.
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung