In article <KANZE.94Nov23200229@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze US/ESC 60/3/141 #40763) writes:
>In article <3agfh5$40d@fsgm01.fnal.gov> b91926@fsgm01.fnal.gov (David
>Sachs) writes:
>
>|> jbuck@synopsys.com (Joe Buck) writes:
>|> ...
>|> According to the ARM, for a non-member function, "inline" implies
>|> "static". I have seen some discussion about allowing a functions to
>|> be both "inline" and "extern".

 Of course, that is not very good English. What it means
is that the linkage of a function declared inline and which
has no previous linkage specified defaults to internal linkage.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <785763647snz@wslint.demon.co.uk> Kevlin@wslint.demon.co.uk writes:
>
>It would make no difference _here_, which is my point. If you want code to
>be inlined then it must be available to many translation units in which
>case you'd shove it in a header. You will get multiple definition problems
>unless you use either static or inline. Since static and inline mean
>different things - I can have many functions w/ the same name in different
>translation units that are declared static, but the same does not apply
>to inline - you still need to distinguish between them. Having a keyword
>such as, for instance, inline [;-)] seems to be a reasonable approach.

 Sigh. Lets get this straight.

 "Inlining" refers to the ability of a
compiler to optimise a function call if it knows the definition
of the function.

 In C++, an "inline" function is one which has the inline
keyword _or_ has an "in-class" definition.

 In C++, a function name/signature pair either has external or
internal linkage.

If two function names have the same signatures, are declared in
the same class/namespace, and have the same name _and_ both have
external linkage, they name the same function. Otherwise, if both
have internal linkage they name _distinct_ functions.

 A function may be identified at run time by its type and address.

 As from San Diego, the "inline" keyword implies internal
linkage by default, but "inline extern" is permitted and specifies
external linkage. Furthermore, all members of non-local classes
have external linkage. In particular, inclass "static" member
functions have external linkage.

 If and when the ODR is settled, it will say something
like this: two definitions may be given for the _same_ function
in different translation units if, and only if, both are
marked inline and equivalent. That is, the function must have the
inline keyword or the definition must be given in-class.

 Therefore, "inline" has definite semantics in C++
-- which are an artefact of the mismatch between the
archaic compilation system and modern notions of optimisation.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

Peter Kukol (peterk@borland.com) wrote:
: In article <3b37is$3fe@news.bridge.com>, rodb@bridge.com says...
: >Actually I have been bitten by this, "as if" the Borland compiler does this
: >optimisation -- but gets it wrong (at least with the "outline" inlines for
: >debug option) -- what I had was:
: >
: >file a.c++:
: >        [static] inline void *align(void &* v)
: >        { /* 32 bit align code cast to long and treat as integer *? }
: >
: >file b.c++:
: >        [static] inline void *align(boid &* v)
: >        { /* same but 64 bit align required! */ }
: >
: >Borland happily had one global copy which meant the programme worked if
: >b linked before a (more stringent requirement) but not if a before b (it
: >would croak in b if the 64 bit alignment didn't happen -- don't ask why
: >I needed this, ugly stuff.

: This is a very unfortunate artifact of trying to satisfy the expectations
: of most users without completely reworking the linker. Let me explain: in
: most cases, inlines with the same name and parameter type(s) are identical
: across compilation units, and users expect them to be merged and only get
: one copy (of those that aren't expanded inline) in the program. Of course,
: this merging should be done only for bodies that actually match, but since
: such a decision needs to be made at link time, it's difficult to implement
: correctly without rather significant changes to the linker. Thus, when you
: want this to work right, you have to disable 'inline merging' via the -Vs
: option (or make sure inlines are expanded inline, of course). Note that
: enabling -Vs will give you duplicates for all out-of-line inlines (and
: other things as well, e.g. vtables), but it should behave 100% correctly
: wrt linkage.

: When (if ever) we get to a true system of type-safe linkage (and get away
: from reliance on simple mangled names), we'll be able to do this right and
: merge only those inlines that have the same definition. I would not hold
: my breath for this, though: it'll be a long wait before this happens :-(.
 You could ofcourse mangle the name further by adding some "check sum"
derived from the generated code (only for global/file scope inline functions)
this would be best if you have some "intermediate representation" so that
such things as optimisation, debug data, and other compiler switches (e.g
model on 80*86?) would not affect the check sum this would then tell you
which such functions were functionally equivalent and candidates for the
above optimisation -- just a tought
  Rod Burman rodb@bridge.com
<this sig intentionally left blank>

In article <CzvuuF.ArJ@ucc.su.OZ.AU>, maxtal@physics.su.OZ.AU (John Max Skaller) writes:
[..]
|>  "Inlining" refers to the ability of a
|> compiler to optimise a function call if it knows the definition
|> of the function.
|>
|>  In C++, an "inline" function is one which has the inline
|> keyword _or_ has an "in-class" definition.
|>
|>  In C++, a function name/signature pair either has external or
|> internal linkage.
|>
[..]
|>  As from San Diego, the "inline" keyword implies internal
|> linkage by default, but "inline extern" is permitted and specifies
|> external linkage. ...

So does "inline extern" mean:
- In all translation-units where the implementation of the
  "extern inline" function is known, the compiler may inline it.
- In the other translation-units a call to an offline implementation
  of this function is generated.
- At least in one of the translation-units where the implementation
  of the "extern inline" function is known (or during linktime)
  one offline implementation of this function has to be generated.

This would be a good thing: It allows inlining in one or more
translation-units that implement some package where the "extern inline"
function belongs to and calls of an extern function in all translation-
units that use this package and that ought not do know about/depend on
the implementation of the "extern inline" function.

Thanx in advance for your answers (affirmation/correction).

Ulf Schuenemann

--------------------------------------------------------------------
Ulf Sch   nemann
Institut f   r Informatik, Technische Universit   t M   nchen.
email: schuenem@informatik.tu-muenchen.de

In article <3agfh5$40d@fsgm01.fnal.gov> b91926@fsgm01.fnal.gov (David
Sachs) writes:

|> jbuck@synopsys.com (Joe Buck) writes:
|> ...
|> >Not necessarily.  It may be possible to generate only a single copy of
|> >such "inline failures" provided that there is a systematic way to choose
|> >which module should contain the definition.  This is done in g++ with
|> >#pragma interface and could be done in compilers with a repository
|> >mechanism for instantiating templates by "instantiating" the "inline failures"
|> >in the same pre-link step.

|> Actually, a standard conforming compiler MUST generate a separate
|> copy of every non-member inline function for each program unit, though
|> they could be omitted for program units that do not call them.

|> According to the ARM, for a non-member function, "inline" implies
|> "static". I have seen some discussion about allowing a functions to
|> be both "inline" and "extern".

Inline does imply static, but that doesn't require a standards
conforming compiler to generate a copy of every non-member inline
function in each unit.  It only requires that the visible results of
running the program be the same as if it had generated such a copy.

In the case of inline functions, if the function contains no static
variables, I think one global copy plus one copy in each translation
unit which takes the address of the function would do the trick.
--
James Kanze      Tel.: (+33) 88 14 49 00     email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

James Kanze US/ESC 60/3/141 #40763 (kanze@us-es.sel.de) wrote:
: In article <3agfh5$40d@fsgm01.fnal.gov> b91926@fsgm01.fnal.gov (David
: Sachs) writes:

: |> jbuck@synopsys.com (Joe Buck) writes:
: |> ...
: |> >Not necessarily.  It may be possible to generate only a single copy of
: |> >such "inline failures" provided that there is a systematic way to choose
: |> >which module should contain the definition.  This is done in g++ with
: |> >#pragma interface and could be done in compilers with a repository
: |> >mechanism for instantiating templates by "instantiating" the "inline failures"
: |> >in the same pre-link step.

: |> Actually, a standard conforming compiler MUST generate a separate
: |> copy of every non-member inline function for each program unit, though
: |> they could be omitted for program units that do not call them.

: |> According to the ARM, for a non-member function, "inline" implies
: |> "static". I have seen some discussion about allowing a functions to
: |> be both "inline" and "extern".

: Inline does imply static, but that doesn't require a standards
: conforming compiler to generate a copy of every non-member inline
: function in each unit.  It only requires that the visible results of
: running the program be the same as if it had generated such a copy.

: In the case of inline functions, if the function contains no static
: variables, I think one global copy plus one copy in each translation
: unit which takes the address of the function would do the trick.
: --
: James Kanze      Tel.: (+33) 88 14 49 00     email: kanze@lts.sel.alcatel.de
: GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
: Conseils en informatique industrielle --
:                               -- Beratung in industrieller Datenverarbeitung

Actually I have been bitten by this, "as if" the Borland compiler does this
optimisation -- but gets it wrong (at least with the "outline" inlines for
debug option) -- what I had was:

file a.c++:
 [static] inline void *align(void &* v)
 { /* 32 bit align code cast to long and treat as integer *? }

file b.c++:
 [static] inline void *align(boid &* v)
 { /* same but 64 bit align required! */ }

Borland happily had one global copy which meant the programme worked if
b linked before a (more stringent requirement) but not if a before b (it
would croak in b if the 64 bit alignment didn't happen -- don't ask why
I needed this, ugly stuff.

Note I added the static's to work around the bug when I found it, to no
avail Borland still got me.

Final work around align32 and align64! So I suspect this optimisation in
real life would make for a lot of odd bugs (it certainly took me a while
to find it was calling a "static" in another module!
 Rod Burman

In article <3b37is$3fe@news.bridge.com>, rodb@bridge.com says...
>Actually I have been bitten by this, "as if" the Borland compiler does this
>optimisation -- but gets it wrong (at least with the "outline" inlines for
>debug option) -- what I had was:
>
>file a.c++:
>        [static] inline void *align(void &* v)
>        { /* 32 bit align code cast to long and treat as integer *? }
>
>file b.c++:
>        [static] inline void *align(boid &* v)
>        { /* same but 64 bit align required! */ }
>
>Borland happily had one global copy which meant the programme worked if
>b linked before a (more stringent requirement) but not if a before b (it
>would croak in b if the 64 bit alignment didn't happen -- don't ask why
>I needed this, ugly stuff.

This is a very unfortunate artifact of trying to satisfy the expectations
of most users without completely reworking the linker. Let me explain: in
most cases, inlines with the same name and parameter type(s) are identical
across compilation units, and users expect them to be merged and only get
one copy (of those that aren't expanded inline) in the program. Of course,
this merging should be done only for bodies that actually match, but since
such a decision needs to be made at link time, it's difficult to implement
correctly without rather significant changes to the linker. Thus, when you
want this to work right, you have to disable 'inline merging' via the -Vs
option (or make sure inlines are expanded inline, of course). Note that
enabling -Vs will give you duplicates for all out-of-line inlines (and
other things as well, e.g. vtables), but it should behave 100% correctly
wrt linkage.

When (if ever) we get to a true system of type-safe linkage (and get away
from reliance on simple mangled names), we'll be able to do this right and
merge only those inlines that have the same definition. I would not hold
my breath for this, though: it'll be a long wait before this happens :-(.

>Note I added the static's to work around the bug when I found it, to no
>avail Borland still got me.

That makes no difference, since non-member inlines have internal linkage
by default.

-------------------------------------------------------------------------

I wish I could give you a better workaround, but I'm afraid we'll be with
this compromise for a while more, so -Vs or -vi is the only way to solve
this particular problem. I don't think other implementations that merge
duplicate out-of-line inlines across compilation units are likely to fare
any better (those that use a (semi-)ordinary linker, that is), because
they run into the same problem.

Thanks
Peter

In article <JASON.94Nov18201327@phydeaux.cygnus.com>
           jason@cygnus.com "Jason Merrill" writes:

>>>>>> Kevlin Henney <kevlin@wslint.demon.co.uk> writes:
>
>>> Nope; a recent discussion of inline functions in comp.std.c noted the
>>> similarities...and some came to the conclusion that adding the 'inline'
>>> hint to C was not useful, since compilers can do it on their own.
>
>> Unless C compilers have changed while I had my back turned, I think
>> you'll find this not to be the case:
>
>>       /* file1.c */
>>       extern void foo(void);
>>       void bar(void)
>>       {
>>               foo();
>>       }
>
>>       /* file2.c */
>>       void foo(void)
>>       {
>>       }
>
>> Suggestions as to how to inline foo in bar using the current model of
>> compilation and linkage are welcome ;-)
>
>Emit no code until the entire translation unit has been parsed; do inlining
>and final compilation at that point.  And make sure you have a lot of swap
>space :)

What are you talking about? I'm talking about compilers that inline code that
is not declared inline, in which case definitions will not be generally
available to the compiler across translation units.

>In any case, how would the 'inline' keyword make any difference here?

It would make no difference _here_, which is my point. If you want code to
be inlined then it must be available to many translation units in which
case you'd shove it in a header. You will get multiple definition problems
unless you use either static or inline. Since static and inline mean
different things - I can have many functions w/ the same name in different
translation units that are declared static, but the same does not apply
to inline - you still need to distinguish between them. Having a keyword
such as, for instance, inline [;-)] seems to be a reasonable approach.

+---------------------------+-------------------------------------------+
| Kevlin A P Henney         | Human vs Machine Intelligence:            |
| kevlin@wslint.demon.co.uk | Humans can wreck a nice beach more easily |
| Westinghouse Systems Ltd  |                                           |
+---------------------------+-------------------------------------------+

>>>>> Kevlin Henney <kevlin@wslint.demon.co.uk> writes:

>> Nope; a recent discussion of inline functions in comp.std.c noted the
>> similarities...and some came to the conclusion that adding the 'inline'
>> hint to C was not useful, since compilers can do it on their own.

> Unless C compilers have changed while I had my back turned, I think
> you'll find this not to be the case:

>  /* file1.c */
>  extern void foo(void);
>  void bar(void)
>  {
>   foo();
>  }

>  /* file2.c */
>  void foo(void)
>  {
>  }

> Suggestions as to how to inline foo in bar using the current model of
> compilation and linkage are welcome ;-)

Emit no code until the entire translation unit has been parsed; do inlining
and final compilation at that point.  And make sure you have a lot of swap
space :)

In any case, how would the 'inline' keyword make any difference here?

Jason

In article <JASON.94Nov18201327@phydeaux.cygnus.com> jason@cygnus.com (Jason Merrill) writes:
>>>>>> Kevlin Henney <kevlin@wslint.demon.co.uk> writes:
>
>>  /* file1.c */
>>  extern void foo(void);
>>  void bar(void)
>>  {
>>   foo();
>>  }
>
>>  /* file2.c */
>>  void foo(void)
>>  {
>>  }
>
>> Suggestions as to how to inline foo in bar using the current model of
>> compilation and linkage are welcome ;-)
>
>Emit no code until the entire translation unit has been parsed; do inlining
>and final compilation at that point.  And make sure you have a lot of swap
>space :)

 Better. Define "compilation" as follows:

 "cp x.cc x.o"

 When you get up to "link", compile the whole lot at once.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <1994Nov15.024118.11668@nlm.nih.gov>, rubenst%occs.nlm.nih.gov says...
>Some compilers don't inline functions with loops simply because it's likely
>not to help much.  Inlining gives little advantage unless the cost of the
>computation in a function is small or compared to the cost of a function call.
>That's likely not to be true if the function contains a loop.

The reason C++ compilers that do inlining in the front-end (which is the
case with quite a few) don't inline functions with loops is that usually
they have to convert the body of an inline to a C-like expression for the
code generator. Thus, if/else statements can be turned into ?: expressions,
but there is no easy way of doing this for loops, goto's, and so on. Now,
it just so happens that inlining functions with things like loops/switches
is indeed quite often a bad idea (except when the parameters happen to be
constants and the body can be folded), so this inline expansion limitation
tends to work out pretty well on real code.

Peter

In article <1994Nov15.122807.9074@unix.brighton.ac.uk> ddv@unix.brighton.ac.uk ( Domenico De Vitto        {spider}) writes:
>Matt Austern (matt@physics2.berkeley.edu) wrote:
>: In article <CzA7uu.3BK@srgenprp.sr.hp.com> keson@sl9.sr.hp.com (Keson Khieu) writes:
>
>: Incidentally, am I the only person who thinks that "inline" is
>: analogous to "register"?
>
>I do.
>

 Inline is more than a hint. It has specific semantics
in terms of the One Definition Rule: only one definition may
given for non-inline functions. More than one definition
may be given for inline functions, provided they are equivalent.

 This is an artefact of the rather old fashioned C
separate compilation system. Getting rid of distinct semantics
for inline -- and the One Definition Rule -- requires a more modern
module based compilation system.

 The committee has approved explicit "extern inline" functions,
but we had them before: class members including static member
functions could already be defined "in-class". Both these entities
would have required equivalence whether or not they had external
linkage -- internal linkage has a serious problem in that
it prevents the address of such members being taken and
comparisons depended on (addresses of such functions are
required to be _distinct_). External linkage mandates these
functions have the _same_ addresses, making comparisons
valid in member functions -- but creating a minor
problem for implementors.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <MATT.94Nov14230614@physics2.berkeley.edu>,
Matt Austern <matt@physics.berkeley.edu> wrote:
:Incidentally, am I the only person who thinks that "inline" is
:analogous to "register"?  Some people might not remember the
:"register" keyword at all, actually: it is (or was, since it's all but
:obsolete by now---I can't remember the last time I actually saw it in
:a program) a hint to the compiler that a certain variable ought to be
:treated specially because it will be used frequently.  Nowadays, most
:compilers ignore that hint: they have optimizers that can figure such
:things out better than most human programmers.  I bet that in five
:years, as optimizer technology improves, "inline" will be just as
:irrelevant as "register".
:--
:
:                               --matt

First of all I don't think that inline is completely analogous to register
because the register keyword is generally found in a src module (i.e. a
file that is not compiled into more than one object module) whereas inline
is found in a header module.  How does a compiler inline a function that
is defined in another src module?  Admittedly, I don't know much about
optimizers, but I can't figure out how it could optimize something that
it doesn't know the definition of.

Incidently, I noticed one very aggravating thing about cfront and inlining.
When I use the -g option to turn on debugging information, cfront does no
inlining (so that the function can be debugged.)  The problem is that it
creates static functions in *every* file for *every* inline function that
it encounters for that compilation unit.  If it would only create a static
function for those inline functions that are actually invoked from within
that module, it would cut down on the size of the executable immensely.
--
Stephen Gevers
sg3235@shelob.sbc.com

Matt Austern <matt@physics.berkeley.edu> wrote:
>>...Incidentally, am I the only person who thinks that "inline" is
>>analogous to "register"?

pap@sgi.com writes:
>The difference though is that if you have a header file with inline
>function definitions and the compile ignores the inline all together, each
>function that was specified must be available and since that in a single
>object file you don't know if it will be available, the compiler must then
>make a local copy (static).

Not necessarily.  It may be possible to generate only a single copy of
such "inline failures" provided that there is a systematic way to choose
which module should contain the definition.  This is done in g++ with
#pragma interface and could be done in compilers with a repository
mechanism for instantiating templates by "instantiating" the "inline failures"
in the same pre-link step.

But these are implementation issues, not standards issues, perhaps better
discussed on comp.lang.c++.

--
-- Joe Buck  <jbuck@synopsys.com> (not speaking for Synopsys, Inc)

In article <3adn65$dlo@ritz.cec.wustl.edu> sg3235@shelob.sbc.com writes:
>In article <MATT.94Nov14230614@physics2.berkeley.edu>,
>Matt Austern <matt@physics.berkeley.edu> wrote:
>:Incidentally, am I the only person who thinks that "inline" is
>:analogous to "register"?  Some people might not remember the
>:"register" keyword at all, actually: it is (or was, since it's all but
>:obsolete by now---I can't remember the last time I actually saw it in
>:a program) a hint to the compiler that a certain variable ought to be
>:treated specially because it will be used frequently.  Nowadays, most
>:compilers ignore that hint: they have optimizers that can figure such
>:things out better than most human programmers.  I bet that in five
>:years, as optimizer technology improves, "inline" will be just as
>:irrelevant as "register".
>:--
>:
>:                               --matt
>
>First of all I don't think that inline is completely analogous to register
>because the register keyword is generally found in a src module (i.e. a
>file that is not compiled into more than one object module) whereas inline
>is found in a header module.  How does a compiler inline a function that
>is defined in another src module?  Admittedly, I don't know much about
>optimizers, but I can't figure out how it could optimize something that
>it doesn't know the definition of.
>
>Incidently, I noticed one very aggravating thing about cfront and inlining.
>When I use the -g option to turn on debugging information, cfront does no
>inlining (so that the function can be debugged.)  The problem is that it
>creates static functions in *every* file for *every* inline function that
>it encounters for that compilation unit.  If it would only create a static
>function for those inline functions that are actually invoked from within
>that module, it would cut down on the size of the executable immensely.
>--
>Stephen Gevers
>sg3235@shelob.sbc.com

cback will filter out the out-of-line inlines that are not referenced.


Ze'ev Mehler
-------------------------------------------------------------------------------
NewCode Technology, Inc.   Tel: (508) 454-7255
650 Suffolk St.     Fax: (508) 454-7559
Lowell, MA 01854    Email: zeev@newcode.com
-------------------------------------------------------------------------------

jbuck@synopsys.com (Joe Buck) writes:
...
>Not necessarily.  It may be possible to generate only a single copy of
>such "inline failures" provided that there is a systematic way to choose
>which module should contain the definition.  This is done in g++ with
>#pragma interface and could be done in compilers with a repository
>mechanism for instantiating templates by "instantiating" the "inline failures"
>in the same pre-link step.

Actually, a standard conforming compiler MUST generate a separate
copy of every non-member inline function for each program unit, though
they could be omitted for program units that do not call them.

According to the ARM, for a non-member function, "inline" implies
"static". I have seen some discussion about allowing a functions to
be both "inline" and "extern".

In article <JASON.94Nov15002416@phydeaux.cygnus.com>
           jason@cygnus.com "Jason Merrill" writes:

>>>>>> Matt Austern <matt@physics2.berkeley.edu> writes:
>
>> Incidentally, am I the only person who thinks that "inline" is
>> analogous to "register"?
>
>Nope; a recent discussion of inline functions in comp.std.c noted the
>similarities...and some came to the conclusion that adding the 'inline'
>hint to C was not useful, since compilers can do it on their own.
>
>Jason

Unless C compilers have changed while I had my back turned, I think
you'll find this not to be the case:

 /* file1.c */
 extern void foo(void);
 void bar(void)
 {
  foo();
 }

 /* file2.c */
 void foo(void)
 {
 }

Suggestions as to how to inline foo in bar using the current model of
compilation and linkage are welcome ;-)

+---------------------------+-------------------------------------------+
| Kevlin A P Henney         | Human vs Machine Intelligence:            |
| kevlin@wslint.demon.co.uk | Humans can wreck a nice beach more easily |
| Westinghouse Systems Ltd  |                                           |
+---------------------------+-------------------------------------------+

Stroustrup in his ARM stated that inline hint may not be granted if a
function has loop, switch, among other things.

If inline can handle "if", why can't it handle switch, loop, etc.  Stroustrup
did not say why.  Don't they all have to generate labels/gotos under the cover?

If you know the answer, please help.

Thanks, Keson.

>>>>> Keson Khieu <keson@sl9.sr.hp.com> writes:

> If inline can handle "if", why can't it handle switch, loop, etc.
> Stroustrup did not say why.  Don't they all have to generate labels/gotos
> under the cover?

This has nothing to do with the C++ standard.  Some implementations can,
others can't.

Jason

In article <CzA7uu.3BK@srgenprp.sr.hp.com> keson@sl9.sr.hp.com (Keson Khieu) writes:

> Stroustrup in his ARM stated that inline hint may not be granted if a
> function has loop, switch, among other things.

Ellis and Stroustrup say no such thing.  They say (correctly, of
course) that "inline" is simply a hint to the compiler that a function
will be used frequently, and that it should be handled in some
especially efficient fashion.  They also say that a compiler may,
depending on the specifics of the function, choose to disregard that
hint.  In fact, note that an implementation that ignores inline
altogether would still be conforming.

Ellis and Stroustrup point out that some implementations will
disregard this hint if the function contains a loop, but that, on some
architectures (e.g., vector machines), implementations ought to inline
loops.

Incidentally, am I the only person who thinks that "inline" is
analogous to "register"?  Some people might not remember the
"register" keyword at all, actually: it is (or was, since it's all but
obsolete by now---I can't remember the last time I actually saw it in
a program) a hint to the compiler that a certain variable ought to be
treated specially because it will be used frequently.  Nowadays, most
compilers ignore that hint: they have optimizers that can figure such
things out better than most human programmers.  I bet that in five
years, as optimizer technology improves, "inline" will be just as
irrelevant as "register".
--

                               --matt

Keson Khieu (keson@sl9.sr.hp.com) wrote:
> Stroustrup in his ARM stated that inline hint may not be granted if a
> function has loop, switch, among other things.

> If inline can handle "if", why can't it handle switch, loop, etc.  Stroustrup
> did not say why.  Don't they all have to generate labels/gotos under the cover?

> If you know the answer, please help.

That's intended as an example of a reason a compiler might not honor an
inline request.  The language gives the implementor complete freedom in
deciding whether to inline a function.

Some compilers don't inline functions with loops simply because it's likely
not to help much.  Inlining gives little advantage unless the cost of the
computation in a function is small or compared to the cost of a function call.
That's likely not to be true if the function contains a loop.

It might be a good idea to inline such functions though and other compilers
will do so.  Note the paragraph after the statement about not inlining
functions containing a loop, switch, or goto:

 Limitations on inlining will vary from implementation to
 implementation.  The limitations above are the ones found in the
 original C++ implementation.  It is easy to do better.

  ARM 7.1.2

--
Mike Rubenstein

In article <MATT.94Nov14230614@physics2.berkeley.edu>,
Matt Austern <matt@physics.berkeley.edu> wrote:
>In article <CzA7uu.3BK@srgenprp.sr.hp.com> keson@sl9.sr.hp.com (Keson Khieu) writes:
>
>> Stroustrup in his ARM stated that inline hint may not be granted if a
>> function has loop, switch, among other things.
>
>Ellis and Stroustrup say no such thing.  They say (correctly, of
>course) that "inline" is simply a hint to the compiler that a function
>will be used frequently, and that it should be handled in some
>especially efficient fashion.  They also say that a compiler may,
>depending on the specifics of the function, choose to disregard that
>hint.  In fact, note that an implementation that ignores inline
>altogether would still be conforming.
>
>Ellis and Stroustrup point out that some implementations will
>disregard this hint if the function contains a loop, but that, on some
>architectures (e.g., vector machines), implementations ought to inline
>loops.
>
>Incidentally, am I the only person who thinks that "inline" is
>analogous to "register"?  Some people might not remember the
>"register" keyword at all, actually: it is (or was, since it's all but
>obsolete by now---I can't remember the last time I actually saw it in
>a program) a hint to the compiler that a certain variable ought to be
>treated specially because it will be used frequently.

The difference though is that if you have a header file with inline
function definitions and the compile ignores the inline all together, each
function that was specified must be available and since that in a single
object file you don't know if it will be available, the compiler must then
make a local copy (static).  This is what is known as the inline code
bloat.  Cfront includes ALL inline functions that it will not inline
as static whether or not it was called.   First thought would be to
think that if you turn on certain options to determine that these functions
were not inlined then take them out of line and this is true in most
cases.  The difficult part is when your writing a "filter" to convert
some language to C++ and you as the programmer don't know whether it
will be inlined.

> Nowadays, most
>compilers ignore that hint: they have optimizers that can figure such
>things out better than most human programmers.  I bet that in five
>years, as optimizer technology improves, "inline" will be just as
>irrelevant as "register".
>--

Yeah, when we finally go over to interpreted systems.

>
>                               --matt

Patrick

>>>>> Matt Austern <matt@physics2.berkeley.edu> writes:

> Incidentally, am I the only person who thinks that "inline" is
> analogous to "register"?

Nope; a recent discussion of inline functions in comp.std.c noted the
similarities...and some came to the conclusion that adding the 'inline'
hint to C was not useful, since compilers can do it on their own.

Jason

Matt Austern (matt@physics2.berkeley.edu) wrote:
: In article <CzA7uu.3BK@srgenprp.sr.hp.com> keson@sl9.sr.hp.com (Keson Khieu) writes:

: Incidentally, am I the only person who thinks that "inline" is
: analogous to "register"?

I do.

: Some people might not remember the
: "register" keyword at all, actually: it is (or was, since it's all but
: obsolete by now---I can't remember the last time I actually saw it in
: a program) a hint to the compiler that a certain variable ought to be
: treated specially because it will be used frequently.  Nowadays, most
: compilers ignore that hint: they have optimizers that can figure such
: things out better than most human programmers.  I bet that in five
: years, as optimizer technology improves, "inline" will be just as
: irrelevant as "register".

Wrong! a human can often look at the optimisers output and say, well this
would be better.  If you specify 'register' a good compiler should
give it a register if it has one free, and the optimiser not steal the register
back!

The whole point of 'register' and 'inline' is to give the compiler an
indication of what *you* think is best, and the compiler should assume
that you do.

Dom