inline function

Discussion in 'C++' started by jg, Jul 31, 2007.

  1. jg

    jg Guest

    Does C++ standard require an inline function be generated all the
    time ?

    For example,

    #include <iostream>
    using namespace std;

    inline int foo()
    {
    return 10;
    }

    int main()
    {
    cout << "foo()=" << foo() << endl;
    }

    Should foo() be generated in the final executable all the time ?

    JG
     
    jg, Jul 31, 2007
    #1
    1. Advertising

  2. jg

    Guest

    On Jul 31, 8:51 am, jg <> wrote:
    > Does C++ standard require an inline function be generated all the
    > time ?


    inline is just a hint or request of the compiler, and doesn't promise
    anything...

    Tony
     
    , Jul 31, 2007
    #2
    1. Advertising

  3. On Jul 31, 4:51 am, jg <> wrote:
    > Does C++ standard require an inline function be generated all the
    > time ?
    >

    The correct term is "inlined", not "generated".

    Given that, the answer is that the standard doesnot require an inline
    function to be inlined all the time.

    -N
     
    Neelesh Bodas, Jul 31, 2007
    #3
  4. jg

    jg Guest

    On Jul 30, 8:47 pm, Neelesh Bodas <> wrote:
    > On Jul 31, 4:51 am, jg <> wrote:> Does C++ standard require an inline function be generated all the
    > > time ?

    >
    > The correct term is "inlined", not "generated".
    >
    > Given that, the answer is that the standard doesnot require an inline
    > function to be inlined all the time.
    >
    > -N


    No. I mean "generated". Whether an inline function is inlined or not
    is not my question. My question is whether a compiler will generate
    the code for that inline function no matter whether the function
    is inlined or not.

    For my example, I tried g++. Without optimization, it does generate
    foo(); with -O, it does not. With Sun Studio 11, it does not generate
    foo() even without optimization.

    JG



    it does generate that
     
    jg, Jul 31, 2007
    #4
  5. jg

    Ian Collins Guest

    jg wrote:
    > On Jul 30, 8:47 pm, Neelesh Bodas <> wrote:
    >> On Jul 31, 4:51 am, jg <> wrote:> Does C++ standard require an inline function be generated all the
    >>> time ?

    >> The correct term is "inlined", not "generated".
    >>
    >> Given that, the answer is that the standard doesnot require an inline
    >> function to be inlined all the time.
    >>
    >> -N

    >
    > No. I mean "generated". Whether an inline function is inlined or not
    > is not my question. My question is whether a compiler will generate
    > the code for that inline function no matter whether the function
    > is inlined or not.
    >

    The answer has to be yes, if the function is used. Code will either be
    generated inline where it is called, or elsewhere if the compiler
    decides not to inline the function.

    There is no requirement to generate a stand alone function.

    --
    Ian Collins.
     
    Ian Collins, Jul 31, 2007
    #5
  6. jg

    Guest

    On Jul 31, 10:12 am, Ian Collins <> wrote:
    > jg wrote:
    > > On Jul 30, 8:47 pm, Neelesh Bodas <> wrote:
    > >> On Jul 31, 4:51 am, jg <> wrote:> Does C++ standard require an inline function be generated all the
    > >>> time ?
    > >> The correct term is "inlined", not "generated".

    >
    > >> Given that, the answer is that the standard doesnot require an inline
    > >> function to be inlined all the time.

    >
    > >> -N

    >
    > > No. I mean "generated". Whether an inline function is inlined or not
    > > is not my question. My question is whether a compiler will generate
    > > the code for that inline function no matter whether the function
    > > is inlined or not.

    >
    > The answer has to be yes, if the function is used. Code will either be
    > generated inline where it is called, or elsewhere if the compiler
    > decides not to inline the function.
    >
    > There is no requirement to generate a stand alone function.
    >
    > --
    > Ian Collins.


    Hi Jg,
    It is up to the compiler based on the size of the piece of
    inline code constructed by the programmer.
    If the compiler feels not to make the piece as inline(because of
    larger size), it does not generate the inline code.

    Thanks,
    nalla
     
    , Jul 31, 2007
    #6
  7. jg

    James Kanze Guest

    On Jul 31, 1:51 am, jg <> wrote:
    > Does C++ standard require an inline function be generated all the
    > time ?


    > For example,


    > #include <iostream>
    > using namespace std;


    > inline int foo()
    > {
    > return 10;
    > }


    > int main()
    > {
    > cout << "foo()=" << foo() << endl;
    > }


    > Should foo() be generated in the final executable all the time ?


    I'm not sure what you mean by "generated". The language defines
    the semantics of a given C++ program (provided there is no
    undefined behavior). Those semantics result in one or more
    possible "observable behavior". Basically, the language
    standard then says that a compiler can do whatever it wants, as
    long as executing the resulting program results in one of the
    observable behaviors.

    On a Unix, machine, for example, for the above a compiler could
    legally generate something like:
    write( 1, "foo()=10\n", 9 ) ;
    return 0 ;
    Most compilers will probably generate something like:
    cout << "foo()=" << 10 << endl ;
    return 0 ;
    for the above.

    Some compilers might also generate an out of line copy of foo(),
    perhaps to simplify debugging (e.g. if you've asked for
    debugging information). What the compiler generates, however,
    doesn't matter as long as executing the code results in an
    observable behavior which corresponds to the specified
    semantics.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Jul 31, 2007
    #7
  8. wrote:
    > On Jul 31, 10:12 am, Ian Collins <> wrote:
    >> jg wrote:
    >>> On Jul 30, 8:47 pm, Neelesh Bodas <> wrote:
    >>>> On Jul 31, 4:51 am, jg <> wrote:> Does C++ standard require an inline function be generated all the
    >>>>> time ?
    >>>> The correct term is "inlined", not "generated".
    >>>> Given that, the answer is that the standard doesnot require an inline
    >>>> function to be inlined all the time.
    >>>> -N
    >>> No. I mean "generated". Whether an inline function is inlined or not
    >>> is not my question. My question is whether a compiler will generate
    >>> the code for that inline function no matter whether the function
    >>> is inlined or not.

    >> The answer has to be yes, if the function is used. Code will either be
    >> generated inline where it is called, or elsewhere if the compiler
    >> decides not to inline the function.
    >>
    >> There is no requirement to generate a stand alone function.
    >>
    >> --
    >> Ian Collins.

    >
    > Hi Jg,
    > It is up to the compiler based on the size of the piece of
    > inline code constructed by the programmer.
    > If the compiler feels not to make the piece as inline(because of
    > larger size), it does not generate the inline code.


    I think you are all being a bit obtuse here. He is clearly asking
    whether a (non-inlined) subroutine for the function will be generated
    in the final binary regardless of whether the compiler inlined its
    contents in the only place where it was called or not.

    Or if we word it in another way: Even if the compiler inlined the
    contents of the function at the calling location, will the contents
    of the function also exist as a non-inlined function in the final
    binary (even if this non-inlined version is never called anywhere)?

    I don't know what the standard says, but IIRC at least gcc has a
    command-line option to force it to create non-inlined instances of
    inline functions regardless of whether they are necessary or not.
     
    Juha Nieminen, Jul 31, 2007
    #8
  9. jg

    Andre Kostur Guest

    jg <> wrote in news:1185839484.488728.323430
    @b79g2000hse.googlegroups.com:

    > Does C++ standard require an inline function be generated all the
    > time ?
    >
    > For example,
    >
    > #include <iostream>
    > using namespace std;
    >
    > inline int foo()
    > {
    > return 10;
    > }
    >
    > int main()
    > {
    > cout << "foo()=" << foo() << endl;
    > }
    >
    > Should foo() be generated in the final executable all the time ?


    Not necessarily. If the function is declared as inline, the function body
    may never exist in the final executable. There are certain actions which
    will guarantee that it does exist (like taking it's address), and you can't
    guarantee that the function body will _not_ be in the executable.
     
    Andre Kostur, Jul 31, 2007
    #9
  10. jg

    jg Guest

    Thanks for all answers.

    To summarize, C++ standard does not require that the out-of-line code
    of an inline function be generated all the time. It looks like C++
    standard does not have explicit wording about this (at least I don't
    find one); and I take it as whether to generate out-of-line code is a
    up to an implementation.

    The reason I was asking this is that in C Standard (C99), a compiler
    must not generate the out-of-line code of an inline function, even
    there
    are calls to that inline function and those calls are not inlined.
     
    jg, Aug 1, 2007
    #10
  11. jg

    James Kanze Guest

    On Aug 1, 7:44 pm, jg <> wrote:

    > To summarize, C++ standard does not require that the out-of-line code
    > of an inline function be generated all the time. It looks like C++
    > standard does not have explicit wording about this (at least I don't
    > find one); and I take it as whether to generate out-of-line code is a
    > up to an implementation.


    > The reason I was asking this is that in C Standard (C99), a compiler
    > must not generate the out-of-line code of an inline function, even
    > there
    > are calls to that inline function and those calls are not inlined.


    That's wrong. Neither C nor C++ constrain the implementation in
    any way in this regard. In both cases, if a function is
    declared inline, its definition may appear in multiple
    translation units, the compiler is not required to inline it,
    but may just generate a local copy and call it, and the compiler
    is free to generate a local copy even if it does inline the
    function. The only difference is that in C++, the compiler is
    more or less required to "merge" all of the local copies, C
    restricts what you can inline so that a conformant program
    cannot tell whether the local copies have been merged or not.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Aug 2, 2007
    #11
  12. jg

    jg Guest

    On Aug 2, 1:26 am, James Kanze <> wrote:
    > On Aug 1, 7:44 pm, jg <> wrote:
    >
    > > To summarize, C++ standard does not require that the out-of-line code
    > > of an inline function be generated all the time. It looks like C++
    > > standard does not have explicit wording about this (at least I don't
    > > find one); and I take it as whether to generate out-of-line code is a
    > > up to an implementation.
    > > The reason I was asking this is that in C Standard (C99), a compiler
    > > must not generate the out-of-line code of an inline function, even
    > > there
    > > are calls to that inline function and those calls are not inlined.

    >


    To clarify, I meant that C standard requires that the out-of-line copy
    of an INLINE FUNCTION must not be generated in that translation unit.
    And its linkage is external. A call to that inline function, if not
    inlined, must be satisfied by an external definition of that inline
    function in another translation unit.

    > That's wrong. Neither C nor C++ constrain the implementation in


    Unfortunately, that is not wrong. Whether this requirement in C
    is good or not is another issue. If you have C standard (C99),
    you can check its definition of inline function (C defines inline
    function in its own way).

    JG

    > any way in this regard. In both cases, if a function is
    > declared inline, its definition may appear in multiple
    > translation units, the compiler is not required to inline it,
    > but may just generate a local copy and call it, and the compiler
    > is free to generate a local copy even if it does inline the
    > function. The only difference is that in C++, the compiler is
    > more or less required to "merge" all of the local copies, C
    > restricts what you can inline so that a conformant program
    > cannot tell whether the local copies have been merged or not.
    >
     
    jg, Aug 2, 2007
    #12
  13. jg

    James Kanze Guest

    On Aug 2, 6:18 pm, jg <> wrote:
    > On Aug 2, 1:26 am, James Kanze <> wrote:


    > > On Aug 1, 7:44 pm, jg <> wrote:


    > > > To summarize, C++ standard does not require that the
    > > > out-of-line code of an inline function be generated all
    > > > the time. It looks like C++ standard does not have
    > > > explicit wording about this (at least I don't find one);
    > > > and I take it as whether to generate out-of-line code is a
    > > > up to an implementation. The reason I was asking this is
    > > > that in C Standard (C99), a compiler must not generate the
    > > > out-of-line code of an inline function, even there are
    > > > calls to that inline function and those calls are not
    > > > inlined.


    > To clarify, I meant that C standard requires that the
    > out-of-line copy of an INLINE FUNCTION must not be generated
    > in that translation unit.


    Which is simply wrong. Neither the C nor the C++ standard ever
    make any requirements with regards to what is or is not
    generated. The requirements only concern the behavior of the
    compiled code.

    > And its linkage is external. A call to that inline function, if not
    > inlined, must be satisfied by an external definition of that inline
    > function in another translation unit.


    Again, that's not what the C standard says. The C standard says
    that there must be a non-inline definition of the function
    somewhere, and that it is unspecified whether you get the
    non-inline definition (possibly in another translation unit) or
    the inline definition (immediately visible). Except for
    requiring the non-inline definition, and making the behavior
    unspecified (rather than undefined), this is not so radically
    different from the C++ standard. Basically: if a function is
    inline, it can (and doubtlessly will) be defined in many
    different places in the program. In C++, if the definitions are
    not identical, the behavior is undefined. In C, it is
    unspecified which definition you actually get.

    > > That's wrong. Neither C nor C++ constrain the implementation in


    > Unfortunately, that is not wrong. Whether this requirement in C
    > is good or not is another issue. If you have C standard (C99),
    > you can check its definition of inline function (C defines inline
    > function in its own way).


    I did that immediately before posting, thank you. The C
    standard, like the C++ standard, never says the slightest thing
    about what the compiler generates. All it specifies is the
    behavior of the program. In particular, we find: "The function
    specifier may appear more than once; the behavior is the same as
    if it appeared only once. Making a function an inline function
    suggests that calls to the function be as fast as possible. The
    extent to which such suggestions are effective is
    implementation-defined."

    Clearly, whether the compiler lays out an out of line copy or
    not is up to the compiler. (And I rather suspect that the
    "implementation-defined", rather than "unspecified", is a
    defect. I don't really expect a compiler to document its
    choices here, as they doubtlessly depend on optimization and
    debug options.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Aug 3, 2007
    #13
  14. jg

    jg Guest

    On Aug 3, 1:30 am, James Kanze <> wrote:
    > On Aug 2, 6:18 pm, jg <> wrote:
    >
    > > On Aug 2, 1:26 am, James Kanze <> wrote:
    > > > On Aug 1, 7:44 pm, jg <> wrote:
    > > > > To summarize, C++ standard does not require that the
    > > > > out-of-line code of aninlinefunctionbe generated all
    > > > > the time. It looks like C++ standard does not have
    > > > > explicit wording about this (at least I don't find one);
    > > > > and I take it as whether to generate out-of-line code is a
    > > > > up to an implementation. The reason I was asking this is
    > > > > that in C Standard (C99), a compiler must not generate the
    > > > > out-of-line code of aninlinefunction, even there are
    > > > > calls to thatinlinefunctionand those calls are not
    > > > > inlined.

    > > To clarify, I meant that C standard requires that the
    > > out-of-line copy of anINLINEFUNCTIONmust not be generated
    > > in that translation unit.

    >
    > Which is simply wrong. Neither the C nor the C++ standard ever
    > make any requirements with regards to what is or is not
    > generated. The requirements only concern the behavior of the
    > compiled code.
    >
    > > And its linkage is external. A call to thatinlinefunction, if not
    > > inlined, must be satisfied by an external definition of thatinline
    > >functionin another translation unit.

    >
    > Again, that's not what the C standard says. The C standard says
    > that there must be a non-inlinedefinition of thefunction
    > somewhere, and that it is unspecified whether you get the
    > non-inlinedefinition (possibly in another translation unit) or
    > theinlinedefinition (immediately visible). Except for
    > requiring the non-inlinedefinition, and making the behavior
    > unspecified (rather than undefined), this is not so radically
    > different from the C++ standard. Basically: if afunctionisinline, it can (and doubtlessly will) be defined in many
    > different places in the program. In C++, if the definitions are
    > not identical, the behavior is undefined. In C, it is
    > unspecified which definition you actually get.
    >
    > > > That's wrong. Neither C nor C++ constrain the implementation in

    > > Unfortunately, that is not wrong. Whether this requirement in C
    > > is good or not is another issue. If you have C standard (C99),
    > > you can check its definition ofinlinefunction(C definesinline
    > >functionin its own way).

    >
    > I did that immediately before posting, thank you. The C
    > standard, like the C++ standard, never says the slightest thing
    > about what the compiler generates. All it specifies is the
    > behavior of the program. In particular, we find: "Thefunction
    > specifier may appear more than once; the behavior is the same as
    > if it appeared only once. Making afunctionaninlinefunction
    > suggests that calls to thefunctionbe as fast as possible. The
    > extent to which such suggestions are effective is
    > implementation-defined."
    >


    Here is the text from C99, section 6.7.4 (6)

    <quote>
    Any function with internal linkage can be an inline function. For a
    function with external
    linkage, the following restrictions apply: If a function is declared
    with an inline function
    specifier, then it shall also be defined in the same translation unit.
    If all of the
    file scope declarations for a function in a translation unit include
    the inline function
    specifier without extern, then the definition in that translation unit
    is an inline
    definition. An inline definition does not provide an external
    definition for the function,
    and does not forbid an external definition in another translation
    unit. An inline definition
    provides an alternative to an external definition, which a translator
    may use to implement
    any call to the function in the same translation unit. It is
    unspecified whether a call to the
    function uses the inline definition or the external definition.120)
    <end of quote>

    >From the above, you can see that a translator cannot provide an

    external definition of
    the function (that is, no out-of-line code is generated in that
    tranlation unit).

    JG
     
    jg, Aug 3, 2007
    #14
  15. jg

    James Kanze Guest

    On Aug 3, 7:29 pm, jg <> wrote:
    > Here is the text from C99, section 6.7.4 (6)


    > <quote>
    > Any function with internal linkage can be an inline function.
    > For a function with external linkage, the following
    > restrictions apply: If a function is declared with an inline
    > function specifier, then it shall also be defined in the same
    > translation unit. If all of the file scope declarations for a
    > function in a translation unit include the inline function
    > specifier without extern, then the definition in that
    > translation unit is an inline definition. An inline
    > definition does not provide an external definition for the
    > function, and does not forbid an external definition in
    > another translation unit. An inline definition provides an
    > alternative to an external definition, which a translator may
    > use to implement any call to the function in the same
    > translation unit. It is unspecified whether a call to the
    > function uses the inline definition or the external
    > definition.
    > <end of quote>


    > From the above, you can see that a translator cannot provide
    > an external definition of the function (that is, no
    > out-of-line code is generated in that tranlation unit).


    >From the above, I can't see the slightest restriction concerning

    what a compiler generates. Read it again. It is explicitly
    unspecified whether the implementation uses the inline
    definition or the external definition. There's absolutely
    nothing there about what the compiler may or may not generate.

    Given the way linkers have historically worked, the first part
    is sort of true (for a definition of "external" that the
    standarfd doesn't use). The compiler can't do anything which
    would cause the linker to declare multiple definitions. But
    that's totally irrelevant with regards to what you put in
    parentheses. Even with older linkers, all the compiler has to
    do is generate the out of line copy as if it were declared
    static (which is what most early C++ compilers did).

    Again: neither the C nor the C++ ever say anything about what an
    implementation may or may not generate. It's a fundamental
    principal underlying both standards. The compiler can do
    absolutely anything, as long as the observable behavior of the
    program is correct.

    --
    James Kanze (GABI Software) email:james.kanze:gmail.com
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Aug 4, 2007
    #15
  16. jg

    jg Guest

    On Aug 4, 2:14 pm, James Kanze <> wrote:
    > On Aug 3, 7:29 pm, jg <> wrote:
    >
    >
    >
    > > Here is the text from C99, section 6.7.4 (6)
    > > <quote>
    > > Anyfunctionwith internal linkage can be aninlinefunction.
    > > For afunctionwith external linkage, the following
    > > restrictions apply: If afunctionis declared with aninline
    > >functionspecifier, then it shall also be defined in the same
    > > translation unit. If all of the file scope declarations for a
    > >functionin a translation unit include theinlinefunction
    > > specifier without extern, then the definition in that
    > > translation unit is aninlinedefinition. Aninline
    > > definition does not provide an external definition for the
    > >function, and does not forbid an external definition in
    > > another translation unit. Aninlinedefinition provides an
    > > alternative to an external definition, which a translator may
    > > use to implement any call to thefunctionin the same
    > > translation unit. It is unspecified whether a call to the
    > >functionuses theinlinedefinition or the external definition.
    > > <end of quote>
    > > From the above, you can see that a translator cannot provide
    > > an external definition of the function(that is, no
    > > out-of-line code is generated in that tranlation unit).

    >


    > what a compiler generates. Read it again. It is explicitly
    > unspecified whether the implementation uses theinline
    > definition or the external definition.


    Definitely, but this is never my question.

    > There's absolutely
    > nothing there about what the compiler may or may not generate.


    This is what we are arguing now.

    >
    > Given the way linkers have historically worked, the first part
    > is sort of true (for a definition of "external" that the
    > standarfd doesn't use). The compiler can't do anything which
    > would cause the linker to declare multiple definitions. But
    > that's totally irrelevant with regards to what you put in
    > parentheses.


    No, it is relevant. We are discussing an inline function with
    external linkage (ie external function). If the out-of-line
    code is generated in that translation unit and it cannot provide
    the external definition to that function, what would it be ?
    What is its name (or linker symbol) ?

    Don't you agree that "does not provide the external definition"
    means the out-of-line code will not be generated !


    > Even with older linkers, all the compiler has to
    > do is generate the out of line copy as if it were declared
    > static (which is what most early C++ compilers did).


    I know. But it is not C99 conforming. Doing this will
    causes two function pointers to the same external function
    to point to different things!

    >
    > Again: neither the C nor the C++ ever say anything about what an
    > implementation may or may not generate. It's a fundamental
    > principal underlying both standards. The compiler can do
    > absolutely anything, as long as the observable behavior of the
    > program is correct.
    >


    It is a general principle. But remember that what is the
    observable behavior is up to many different explanations, sometimes
    subjective. To one person who works on an linker or a binary tool,
    an additional definition in an object file is observable. To another
    who is debugging his code, he suddenly cannot his function in
    the final executable, which is observerable to him.

    I think we have to restrict our discussion within the context of
    C99 standard and the state-of-art implementation.

    JG
     
    jg, Aug 5, 2007
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Abhi
    Replies:
    2
    Views:
    759
    E. Robert Tisdale
    Jul 3, 2003
  2. Nish
    Replies:
    4
    Views:
    525
    Thomas Stegen
    Oct 8, 2004
  3. TGOS
    Replies:
    3
    Views:
    395
    Kevin Bracey
    Feb 28, 2005
  4. Ajay
    Replies:
    5
    Views:
    412
    Pete Becker
    Apr 1, 2006
  5. Replies:
    7
    Views:
    456
Loading...

Share This Page