Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > What gets inlined?

Reply
Thread Tools

What gets inlined?

 
 
Steven T. Hatton
Guest
Posts: n/a
 
      05-30-2005
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
 
Reply With Quote
 
 
 
 
Alf P. Steinbach
Guest
Posts: n/a
 
      05-30-2005
* 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?
 
Reply With Quote
 
 
 
 
Steven T. Hatton
Guest
Posts: n/a
 
      05-30-2005
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
 
Reply With Quote
 
velthuijsen@hotmail.com
Guest
Posts: n/a
 
      05-30-2005
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).

 
Reply With Quote
 
velthuijsen@hotmail.com
Guest
Posts: n/a
 
      05-30-2005
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).

 
Reply With Quote
 
Rolf Magnus
Guest
Posts: n/a
 
      05-30-2005
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.

 
Reply With Quote
 
Steven T. Hatton
Guest
Posts: n/a
 
      05-30-2005
http://www.velocityreviews.com/forums/(E-Mail Removed) 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
 
Reply With Quote
 
msalters
Guest
Posts: n/a
 
      05-30-2005
(E-Mail Removed) 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

 
Reply With Quote
 
Chris Theis
Guest
Posts: n/a
 
      05-30-2005

"Steven T. Hatton" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> (E-Mail Removed) 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


 
Reply With Quote
 
John Carson
Guest
Posts: n/a
 
      05-30-2005
"Steven T. Hatton" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)
> 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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Return of gets gets John Joyce Ruby 0 04-23-2007 01:38 PM
gets gets John Joyce Ruby 2 03-26-2007 04:00 PM
XMLHttpRequest gets data to display in element but data gets appended not replaces previous! libsfan01 Javascript 5 12-20-2006 06:25 AM
Not only the selected HREF gets surrounded, but the whole row gets surrounded Stefan Mueller HTML 5 07-10-2006 11:53 AM
Next-gen Windows finally gets a name Silverstrand Software 34 09-12-2005 02:57 PM



Advertisments