What gets inlined?

Discussion in 'C++' started by Steven T. Hatton, May 30, 2005.

  1. I know this is, to some extent, implementation dependent, but since the
    Standard specifies an inline specifier, there must be some "reasonable
    assumptions" I can make about what should happen when I inline a function.

    Suppose I have something like this (which, BTW is currently broken in
    Qt-4-rc1):

    inline QWidget* vBox(QWidget* parent) {
    QWidget* box = new QWidget(parent);
    QVBoxLayout* boxLayout = new QVBoxLayout(box);
    box->setLayout(boxLayout);
    return box;
    }

    Clearly, there will be a lot happening between the entry point, and the
    return from the function. My understanding is that all of the object code
    involved will not be inlined, and only the compiled representation of the
    function calls will be placed inline. Is this correct?
    --
    If our hypothesis is about anything and not about some one or more
    particular things, then our deductions constitute mathematics. Thus
    mathematics may be defined as the subject in which we never know what we
    are talking about, nor whether what we are saying is true.-Bertrand Russell
    Steven T. Hatton, May 30, 2005
    #1
    1. Advertising

  2. * Steven T. Hatton:
    > I know this is, to some extent, implementation dependent, but since the
    > Standard specifies an inline specifier, there must be some "reasonable
    > assumptions" I can make about what should happen when I inline a function.
    >
    > Suppose I have something like this (which, BTW is currently broken in
    > Qt-4-rc1):
    >
    > inline QWidget* vBox(QWidget* parent) {
    > QWidget* box = new QWidget(parent);
    > QVBoxLayout* boxLayout = new QVBoxLayout(box);
    > box->setLayout(boxLayout);
    > return box;
    > }
    >
    > Clearly, there will be a lot happening between the entry point, and the
    > return from the function. My understanding is that all of the object code
    > involved will not be inlined, and only the compiled representation of the
    > function calls will be placed inline. Is this correct?


    No. Essentially you can't assume anything. And that's a FAQ:

    <url: http://www.parashift.com/c++-faq-lite/inline-functions.html#faq-9.3>

    If you want optimization, tell your compiler to optimize.

    If you want control over inlining, which is something else, use
    compiler-specific language extensions.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    Alf P. Steinbach, May 30, 2005
    #2
    1. Advertising

  3. Rolf Magnus wrote:

    > Steven T. Hatton wrote:
    >
    >> I know this is, to some extent, implementation dependent, but since the
    >> Standard specifies an inline specifier, there must be some "reasonable
    >> assumptions" I can make about what should happen when I inline a
    >> function.

    >
    > Yes. You can expect to be able to define it in multiple translation units
    > without getting an error. However, you can't assume any inlining to happen
    > or not happen.


    My question has to do with _what_ gets inlined _if_ the compiler inlines the
    function? I suspect that doesn't vary a lot between implementations, but I
    could be wrong.
    --
    If our hypothesis is about anything and not about some one or more
    particular things, then our deductions constitute mathematics. Thus
    mathematics may be defined as the subject in which we never know what we
    are talking about, nor whether what we are saying is true.-Bertrand Russell
    Steven T. Hatton, May 30, 2005
    #3
  4. Steven T. Hatton

    Guest

    Everywhere that the inlined function is visible the function call gets
    replaced by the code in the function with appropiate substitutions for
    return value and the passed variable(s).
    , May 30, 2005
    #4
  5. Steven T. Hatton

    Guest

    Keep forgetting that Google quick reply chucks out the reply to text so
    here again:

    > My question has to do with _what_ gets inlined _if_ the compiler inlines the
    > function? I suspect that doesn't vary a lot between implementations, but I
    > could be wrong.
    > --
    > If our hypothesis is about anything and not about some one or more
    > particular things, then our deductions constitute mathematics. Thus
    > mathematics may be defined as the subject in which we never know what we
    > are talking about, nor whether what we are saying is true.-Bertrand Russell


    If inline occurs the following:
    Everywhere that the inlined function is visible the function call gets
    replaced by the code in the function with appropiate substitutions for
    return value and the passed variable(s).
    , May 30, 2005
    #5
  6. Steven T. Hatton

    Rolf Magnus Guest

    Steven T. Hatton wrote:

    > I know this is, to some extent, implementation dependent, but since the
    > Standard specifies an inline specifier, there must be some "reasonable
    > assumptions" I can make about what should happen when I inline a function.


    Yes. You can expect to be able to define it in multiple translation units
    without getting an error. However, you can't assume any inlining to happen
    or not happen.
    Rolf Magnus, May 30, 2005
    #6
  7. wrote:

    > Everywhere that the inlined function is visible the function call gets
    > replaced by the code in the function with appropiate substitutions for
    > return value and the passed variable(s).


    What happens when the inlined function has calls to other functions? I
    believe it is correct to assume that the object code for these functions
    is /not/ inlined. Unless of course those functions are also declared
    inline, and the compile feels like doing it.
    --
    If our hypothesis is about anything and not about some one or more
    particular things, then our deductions constitute mathematics. Thus
    mathematics may be defined as the subject in which we never know what we
    are talking about, nor whether what we are saying is true.-Bertrand Russell
    Steven T. Hatton, May 30, 2005
    #7
  8. Steven T. Hatton

    msalters Guest

    schreef:
    > Everywhere that the inlined function is visible

    ( and possibly other places as well )
    > the function call gets replaced

    ( it the compiler follows your hint)
    > by the code in the function

    ( or parts of it, e.g. if the compiler can't inline everything)
    > with appropiate substitutions for return value and the passed
    > variable(s).


    It's very much a hint to the compiler. What it does with such a hint
    is intentionally obscure. E.g. I'd expect a very good compiler not to
    inline a catch(...) clause. That's typically cold code, keep that in
    a separate function but do inline the try{ } body.

    HTH,
    Michiel Salters
    msalters, May 30, 2005
    #8
  9. Steven T. Hatton

    Chris Theis Guest

    "Steven T. Hatton" <> wrote in message
    news:...
    > wrote:
    >
    >> Everywhere that the inlined function is visible the function call gets
    >> replaced by the code in the function with appropiate substitutions for
    >> return value and the passed variable(s).

    >
    > What happens when the inlined function has calls to other functions? I
    > believe it is correct to assume that the object code for these functions
    > is /not/ inlined. Unless of course those functions are also declared
    > inline, and the compile feels like doing it.


    Whether the compiler will inline & substitute also subsequent function calls
    in inlined functions is at the mercy of your compiler. There is no general
    rule for this.

    Cheers
    Chris
    Chris Theis, May 30, 2005
    #9
  10. Steven T. Hatton

    John Carson Guest

    "Steven T. Hatton" <> wrote in message
    news:
    > I know this is, to some extent, implementation dependent, but since
    > the Standard specifies an inline specifier, there must be some
    > "reasonable assumptions" I can make about what should happen when I
    > inline a function.
    >
    > Suppose I have something like this (which, BTW is currently broken in
    > Qt-4-rc1):
    >
    > inline QWidget* vBox(QWidget* parent) {
    > QWidget* box = new QWidget(parent);
    > QVBoxLayout* boxLayout = new QVBoxLayout(box);
    > box->setLayout(boxLayout);
    > return box;
    > }
    >
    > Clearly, there will be a lot happening between the entry point, and
    > the return from the function. My understanding is that all of the
    > object code involved will not be inlined, and only the compiled
    > representation of the function calls will be placed inline. Is this
    > correct? --



    Generally, yes, unless the functions called are themselves inline functions.

    Lots of people in these threads talk about it being "all up to the compiler"
    to inline or not inline as it sees fit. With VC++, there is a switch that
    turns on "auto-inlining", whereby the compiler can inline any function it
    wants. With the default settings, however, no function is inlined unless the
    inline keyword is used (or the function definition is in the class
    declaration, since this is equivalent to using the inline keyword), i.e.,
    use of the inline keyword is a necessary, though not sufficient, condition
    for a function to be inlined. For other compilers, I guess you have to
    consult their documentation.

    --
    John Carson
    John Carson, May 30, 2005
    #10
  11. * John Carson:
    >
    > Lots of people in these threads talk about it being "all up to the compiler"
    > to inline or not inline as it sees fit. With VC++, there is a switch that
    > turns on "auto-inlining", whereby the compiler can inline any function it
    > wants. With the default settings, however, no function is inlined unless the
    > inline keyword is used (or the function definition is in the class
    > declaration, since this is equivalent to using the inline keyword), i.e.,
    > use of the inline keyword is a necessary, though not sufficient, condition
    > for a function to be inlined.


    Sorry, the above is incorrect, at least for MSVC 7.1.

    With MSVC 7.1 (to be precise, which is what I just checked out using a
    little test program) there is a switch that turns _off_ the automatic
    inlining behavior. I.e., with that switch the word 'inline' is required.
    And AFAICS there's no switch to _on_ automatic inlining, it's the default.

    In the for-dummies Visual Studio IDE the automatic inlining off switch is
    set by default, and, just to give readers who don't have that IDE an
    impression of how intelligent the designers were, switches that make the
    compiler behave as standard C++ wrt. wchar_t type, 'main', RTTI and more are
    not set by default in the IDE -- it's not a Good Idea to use the compiler
    behavior in a default Microsoft IDE project as any indication of anything.


    > For other compilers, I guess you have to consult their documentation.


    That would also be a good idea for MSVC. ;-)

    /Ob0 Disables inline expansion, which is on by default.

    Not taking the documentation's word for it, because it's often wrong, I
    tested using a simple program and checking the generated machine code.

    Advice: always test reality.


    Hth.,

    - Alf

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    Alf P. Steinbach, May 30, 2005
    #11
  12. Steven T. Hatton

    John Carson Guest

    "Alf P. Steinbach" <> wrote in message
    news:
    > * John Carson:
    >>
    >> Lots of people in these threads talk about it being "all up to the
    >> compiler" to inline or not inline as it sees fit. With VC++, there
    >> is a switch that turns on "auto-inlining", whereby the compiler can
    >> inline any function it wants. With the default settings, however, no
    >> function is inlined unless the inline keyword is used (or the
    >> function definition is in the class declaration, since this is
    >> equivalent to using the inline keyword), i.e., use of the inline
    >> keyword is a necessary, though not sufficient, condition for a
    >> function to be inlined.

    >
    > Sorry, the above is incorrect, at least for MSVC 7.1.
    >
    > With MSVC 7.1 (to be precise, which is what I just checked out using a
    > little test program) there is a switch that turns _off_ the automatic
    > inlining behavior. I.e., with that switch the word 'inline' is
    > required. And AFAICS there's no switch to _on_ automatic inlining,
    > it's the default.


    It is controlled by the /Ob switch. /Ob0 turn off inlining, as you state,
    /Ob1 gives manual inlining and /Ob2 gives auto inlining. If you create a
    project in the IDE in VC++ 7.1, then /Ob2 (automatic) is the default in
    Release mode. I stand corrected on this. It is a change from VC++ 6.0, where
    /Ob1 is the IDE default. The change in defaults was made in VC++ 7.0.


    --
    John Carson
    John Carson, May 31, 2005
    #12
  13. Steven T. Hatton

    Guest

    msalters wrote:
    > schreef:
    > > Everywhere that the inlined function is visible

    > ( and possibly other places as well )


    Could you please explain what you mean by this? And how does the
    compiler/linker figure out what code to use if it can't see the code?

    > > the function call gets replaced

    > ( it the compiler follows your hint)


    Just responded to the lets assume the compiler does follow your hint :)

    > > by the code in the function

    > ( or parts of it, e.g. if the compiler can't inline everything)


    What compiler(s) implement this at the moment? For the few I know it's
    an all or nothing afair.

    > > with appropiate substitutions for return value and the passed
    > > variable(s).

    >
    > It's very much a hint to the compiler. What it does with such a hint
    > is intentionally obscure. E.g. I'd expect a very good compiler not to
    > inline a catch(...) clause. That's typically cold code, keep that in
    > a separate function but do inline the try{ } body.
    >
    > HTH,
    > Michiel Salters
    , May 31, 2005
    #13
  14. Steven T. Hatton

    Old Wolf Guest

    Steven T. Hatton wrote:
    >
    > Suppose I have something like this (which, BTW is currently broken
    > in Qt-4-rc1):
    >
    > inline QWidget* vBox(QWidget* parent) {
    > QWidget* box = new QWidget(parent);
    > QVBoxLayout* boxLayout = new QVBoxLayout(box);
    > box->setLayout(boxLayout);
    > return box;
    > }


    This code is highly non-exception-safe. Is that what you meant
    by 'broken' ? If the 'new QVBoxLayout(box)' call fails (either
    due to lack of memory, or the layout throwing an exception),
    then resources will be leaked.
    I can't see how a project that's supposed to be the basis of
    a stable application, can justify such dreadful code ?
    Old Wolf, May 31, 2005
    #14
  15. Steven T. Hatton

    Rolf Magnus Guest

    Old Wolf wrote:

    > Steven T. Hatton wrote:
    >>
    >> Suppose I have something like this (which, BTW is currently broken
    >> in Qt-4-rc1):
    >>
    >> inline QWidget* vBox(QWidget* parent) {
    >> QWidget* box = new QWidget(parent);
    >> QVBoxLayout* boxLayout = new QVBoxLayout(box);
    >> box->setLayout(boxLayout);
    >> return box;
    >> }

    >
    > This code is highly non-exception-safe. Is that what you meant
    > by 'broken' ?


    Probably not, considering that Qt doesn't use exceptions.

    > If the 'new QVBoxLayout(box)' call fails (either
    > due to lack of memory, or the layout throwing an exception),
    > then resources will be leaked.


    Probably the exception will actually not be caught at all an the process be
    terminated. There isn't much that the program could do anyway.

    > I can't see how a project that's supposed to be the basis of
    > a stable application, can justify such dreadful code ?


    If there is no memory left, the system is likely to be next to unresponsive
    due to excessive swapping. And then, the program cannot do much to react to
    an out-of-memory condition. Opening a window to tell that to the user - or
    even creating a string would require more memory and so cannot be done in
    an exception handler for out-of-memory exceptions.
    Rolf Magnus, May 31, 2005
    #15
  16. OT:Re: What gets inlined?

    Old Wolf wrote:

    > Steven T. Hatton wrote:
    >>
    >> Suppose I have something like this (which, BTW is currently broken
    >> in Qt-4-rc1):
    >>
    >> inline QWidget* vBox(QWidget* parent) {
    >> QWidget* box = new QWidget(parent);
    >> QVBoxLayout* boxLayout = new QVBoxLayout(box);
    >> box->setLayout(boxLayout);
    >> return box;
    >> }

    >
    > This code is highly non-exception-safe. Is that what you meant
    > by 'broken' ? If the 'new QVBoxLayout(box)' call fails (either
    > due to lack of memory, or the layout throwing an exception),
    > then resources will be leaked.
    > I can't see how a project that's supposed to be the basis of
    > a stable application, can justify such dreadful code ?


    Qt cleans up after itself. If QVBoxLayout(box) fails, parent still has a
    handle on box, and will destroy box when it's destroyed. As it turns out,
    Qt does not support the functionality I was trying to use. The
    documentation is out of sync with the current state of the development code
    base. I believe they are dumbing down the widget and layout creation
    features because too many people found it confusing. Unfortunately, I took
    the time, and made the effort to figure it out. Once I understood it, I
    was able to do some really slick stuff with it. Now that they're taking it
    out, all my code is deprecated. :(
    --
    If our hypothesis is about anything and not about some one or more
    particular things, then our deductions constitute mathematics. Thus
    mathematics may be defined as the subject in which we never know what we
    are talking about, nor whether what we are saying is true.-Bertrand Russell
    Steven T. Hatton, Jun 1, 2005
    #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. Andy
    Replies:
    3
    Views:
    291
  2. Alex Vinokur
    Replies:
    7
    Views:
    402
    Greg Comeau
    Nov 15, 2004
  3. Ognen Duzlevski

    Inlined C code and a TypeError

    Ognen Duzlevski, Jan 13, 2004, in forum: Python
    Replies:
    0
    Views:
    288
    Ognen Duzlevski
    Jan 13, 2004
  4. inline functions not inlined

    , Mar 6, 2006, in forum: C Programming
    Replies:
    9
    Views:
    324
    David Resnick
    Mar 7, 2006
  5. sks
    Replies:
    4
    Views:
    305
    Victor Bazarov
    Dec 6, 2005
Loading...

Share This Page