Re: Another inline question
asterisc wrote:
Hi there,
Before getting a binary, there is the following sequence of steps:
- preprocessing
- compilation
- assembly
- linking
While 'preprocessing' is clearly separated into its own step in the
language Standard, the other ones are not really defined so well.
Especially the assembly portion - nowadays most compilers produce
native code in an object file form. Linking is still a step in
most cases.
Is there any rule at which level should the inline work?
No rule.
I mean, where should we see the effect of the inline keyword ?
During compilation 'inline' acts as a suggestion for the compiler
to substitute the call with the body. During linking 'inline' gives
an instruction to only consider a single definition of the function.
IOW, different meanings at different stages.
I have the following fairly simple piece of code:
//test.cpp
#include <iostream>
inline void increment( int& i )
{
++i;
}
#define INCREMENT(i) (++i)
int main()
{
int i = 0;
increment( i );
std::cout << i << endl;
INCREMENT(i);
std::cout << i << endl;
}
The #define is replaced in the preprocessing step.
Right.
As far as I could check, the effect of the inline is only at the
assembling step, where we won't have a call to the increment()
function. (if we apply an optimization)
The preprocessed source looks exactly the same as the .cpp file, only
the #define was expanded.
Is that the normal behavior?
Probably. I've not seen separate assembling step for quite a while,
so I'll just take your word for it.
Another question, how is inline working with a virtual member
function? (if we call that function thru a base pointer which point to
a derived object)
It doesn't. If the function is not known until run-time, like in
the case with a virtual function, it cannot be inlined, can it?
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask