how compiler differentiates inline virtual function? [modified]

[yogish293]

Hi, suppose if i declare any virtual function as an inline how it differentiates from compile time ? Base class object pointer variable may reference to inherited object.How inline works in such case? thank you

modified on Thursday, August 25, 2011 9:24 AM

[CPallini]

Since it can't it won't inline it (inline is just a tip for the compiler). :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]

[Stefan_Lang]

You can inline virtual functions just like any others: either by using the 'inline' keyword, or just by writing the function definition right into the declaration. Sometimes this makes sense (such as for destructors), sometimes it doesn't. It mostly depends on whether or not a compiler is able to decide what class a particular object pointer actually points to. Somtimes this can only be detemined at runtime and in that case, obviously, no inlining will occur. More information and examples can be found on the web, e. g. here: http://msdn.microsoft.com/en-us/magazine/cc301407.aspx[^] or here: http://drdobbs.com/cpp/184403747[^] In short - if the type of an object pointer can only be determined at runtime, then inlining is not possible, even if the base class and all derived classes do have inlined implementations of that function. If you really, absolutely, desperately need a function to be inlined, either make sure that a particular version is being called (if that is even possible), or simply don't use inheritance for that. That said, since inlining is really only the very last step in performance optimization, it's usally not a real issue: if you can't inline, then you just don't.

[Niklas L]

It is actually possible under certain conditions for the compiler to inline virtual functions. Consider the following:

class Base
{
virtual void func() {...}
};
class Derived : public Base
{
virtual void func() {...}
};

Base b;
b.func();
Derived d;
d.func();

In both cases, the compiler can chose to inline func.

[CPallini]

Yes, you are right, I should have written: "the compiler cannot always inline virtual functions...". However, the rationale behind virtual function is for supporting polymorphism, hence I assumed, in my answer, that late binding was the case of interest.

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]

[Stefan_Lang]

There are two rather common examples where virtual functions are resolved statically, and therefore can be inlined without problem: 1. Explicitely calling the base class implementation 2. Virtual destructors. The compiler will automatically create a chain of calls to destructors according to the inheritance chain. These are resolved statically. The only thing that may be resolved dynamically (at runtime) is the top level call, and even that only if the compiler cannot determine the actual class at compile time

class Shape {
bool state;
public:
inline virtual void initialize() {
state = false;
}
inline virtual ~Shape() {} // will always be resolved statically!
};

class Square : public Shape {
float width;
public:
virtual void initialize() {
Shape::initialize(); // resolved statically - this can be inlined!
width = 0.;
}
~inline virtual ~Square() {} // may be resolved statically
};

int main() {
Shape* pShape = new Square;
pShape->initialize;
delete pShape; // calls pShape->Shape::~Shape() and then pShape->Square::~Square()
// this can be resolved statically since the compiler at this point knows the type
return 0;
}