Inline Virtual Functions
2012-08-10 16:45
183 查看
From: http://msdn.microsoft.com/zh-cn/magazine/cc301407(en-us).aspx
How does C++ handle inline virtual functions? When a function is inline and virtual, will code substitution take place
or is the call resolved using the vtable?
G.N. Rajagopal
The answer is, it depends. To see why, let's consider each caseâ"inline and virtualâ"separately. Normally, an inline
function is expanded, well, inline.
In this situation, if you write
then the compiler generates the code as if you'd written:
Of course you can't do this because val is private. Inline functions give you the advantage of data hiding without
paying the price of a function call. So much for inline functions.
Virtual functions give you polymorphism, which means derived classes can implement the same function differently.
Suppose GetVal is now declared virtual and you have a second class, CFoo2, with a different implementation:
If pFoo is a pointer to a CFoo or CFoo2, then pFoo->GetVal will call the member function for whichever class pFoo
really points toâ"CFoo or CFoo2. This is C++ 101, and you should know it like the back of your hand.
But what happens if a function is both virtual and inline? Remember, there are two ways to make a function inline:
by using the inline keyword in the function definition, as in
or by coding the function body inline within the class declaration, as in the previous CFoo2::GetVal example. So if
you include the body of your virtual function within the class declaration
then you are telling the compiler you want GetVal to be both inline and virtual.
This doesn't seem to make sense, for how can polymorphism work if the function is expanded inline? The answer, of course, is that it can't. Or can it?
The first rule the compiler follows when it encounters such a beast is this: whatever happens, polymorphism
must work. If you have a pointer to a CFoo object, then pFoo->GetVal is guaranteed to call the right function. In general, this means the GetVal functions will be instantiated as real (noninline) functions, with vtable entries pointing to them. But that doesn't
mean the function can't ever be expanded! Consider this code again:
The compiler knows that x is
really a CFoo, not a CFoo2, since the stack object is explicitly declared. There's no way x could
really be a CFoo2. So it's safe to expand SetVal/GetVal inline. If you write this more complex code
the compiler knows that pfoo points to x the
first time and x2
the second time, so again it's safe to expand the virtual functions. You can dream up ever more complex examples, where the type of object pfoo points to is always known, but most compilers won't do any heavy analysis. Even in the preceding example, some compilers
will do the safe thing, which is to instantiate the function and call through a vtable. Indeed, the compiler is free to ignore the inline requirement and always use
the vtable. The only absolute rule is that the code must work; that is, virtual functions must behave polymorphically.
In general, inlineâ"whether explicit or implicitâ"is a hint, not a mandate, just like register. (Does anyone
remember register? It asks the compiler to use a machine register for a variable if it can.) The compiler can refuse to expand even a nonvirtual inline function if it wants to, and the first C++ compilers often complained, "inline abortedâ"function too big."
Certainly if an inline function calls itself, or if you pass its address somewhere, the compiler must generate a normal (outline?) function. And, of course, inline functions are not expanded in debug builds, or if you set a compiler option preventing it.
The only way to really know what your compiler is doing is to look at the code it generates. For the Microsoft®
compiler, you can compile with -FA to generate an assembly listing. You don't need to be an assembler jock to know what's going on. I encourage you to perform this experiment; it's good for the soul to see what the machine is actually doing, and you can learn
a lot poking around assembly listings. For now, I'll spare you that agony.
The topic of inline functions is more complex than you might think at first. There are many circumstances that
force the compiler to generate a normal function: recursion, taking the address of your function, functions that are too big, and virtual functions. Here's another consideration: if the compiler decides to instantiate your inline function, where does it put
the function? Which module does it go into?
Usually, classes are declared in header (.h) files. So if mumble.cpp includes foo.h and the compiler decides
it has to instantiate CFoo:: GetVal, it will instantiate it as a static function in mumble.cpp. If 10 modules include foo.h, the compiler could generate up to 10 copies of your virtual function. In fact, you could end up with objects of the same type with
vtables pointing to different copies of GetVal. Yuk! Some linkers are smart enough to eliminate the redundancies at link time, but in general you can't be sure.
So the bottom line is:
it's best not to use inline virtual functions, since they're almost never expanded anyway. Even if your function is just one line, you're better off putting it in the module (.cpp file) along with the other class functions. Of course, programmers
often put short virtual functions in the class declarationâ"not because they expect the function to be expanded inline, but because it's more convenient and readable.
Q |
or is the call resolved using the vtable?
G.N. Rajagopal
A |
function is expanded, well, inline.
class CFoo { private: int val; public: int GetVal() { return val; } int SetVal(int v) { return val=v; } }; |
CFoo x; x.SetVal(17); int y = x.GetVal(); |
CFoo x; x.val = 17; int y = x.val; |
paying the price of a function call. So much for inline functions.
Virtual functions give you polymorphism, which means derived classes can implement the same function differently.
Suppose GetVal is now declared virtual and you have a second class, CFoo2, with a different implementation:
class CFoo2 : public CFoo { public: // virtual in base class too! virtual int CFoo2::GetVal() { return someOtherVal; } }; |
really points toâ"CFoo or CFoo2. This is C++ 101, and you should know it like the back of your hand.
But what happens if a function is both virtual and inline? Remember, there are two ways to make a function inline:
by using the inline keyword in the function definition, as in
inline CFoo::GetVal() { return val; } |
you include the body of your virtual function within the class declaration
class CFoo { public: virtual int GetVal() { return val; } }; |
This doesn't seem to make sense, for how can polymorphism work if the function is expanded inline? The answer, of course, is that it can't. Or can it?
The first rule the compiler follows when it encounters such a beast is this: whatever happens, polymorphism
must work. If you have a pointer to a CFoo object, then pFoo->GetVal is guaranteed to call the right function. In general, this means the GetVal functions will be instantiated as real (noninline) functions, with vtable entries pointing to them. But that doesn't
mean the function can't ever be expanded! Consider this code again:
CFoo x; x.SetVal(17); int y = x.GetVal(); |
really a CFoo, not a CFoo2, since the stack object is explicitly declared. There's no way x could
really be a CFoo2. So it's safe to expand SetVal/GetVal inline. If you write this more complex code
CFoo x; CFoo* pfoo=&x; pfoo->SetVal(17); int y = pfoo->GetVal(); ��� CFoo2 x2; pfoo = &x2; pfoo->SetVal(17); //etc. |
first time and x2
the second time, so again it's safe to expand the virtual functions. You can dream up ever more complex examples, where the type of object pfoo points to is always known, but most compilers won't do any heavy analysis. Even in the preceding example, some compilers
will do the safe thing, which is to instantiate the function and call through a vtable. Indeed, the compiler is free to ignore the inline requirement and always use
the vtable. The only absolute rule is that the code must work; that is, virtual functions must behave polymorphically.
In general, inlineâ"whether explicit or implicitâ"is a hint, not a mandate, just like register. (Does anyone
remember register? It asks the compiler to use a machine register for a variable if it can.) The compiler can refuse to expand even a nonvirtual inline function if it wants to, and the first C++ compilers often complained, "inline abortedâ"function too big."
Certainly if an inline function calls itself, or if you pass its address somewhere, the compiler must generate a normal (outline?) function. And, of course, inline functions are not expanded in debug builds, or if you set a compiler option preventing it.
The only way to really know what your compiler is doing is to look at the code it generates. For the Microsoft®
compiler, you can compile with -FA to generate an assembly listing. You don't need to be an assembler jock to know what's going on. I encourage you to perform this experiment; it's good for the soul to see what the machine is actually doing, and you can learn
a lot poking around assembly listings. For now, I'll spare you that agony.
The topic of inline functions is more complex than you might think at first. There are many circumstances that
force the compiler to generate a normal function: recursion, taking the address of your function, functions that are too big, and virtual functions. Here's another consideration: if the compiler decides to instantiate your inline function, where does it put
the function? Which module does it go into?
Usually, classes are declared in header (.h) files. So if mumble.cpp includes foo.h and the compiler decides
it has to instantiate CFoo:: GetVal, it will instantiate it as a static function in mumble.cpp. If 10 modules include foo.h, the compiler could generate up to 10 copies of your virtual function. In fact, you could end up with objects of the same type with
vtables pointing to different copies of GetVal. Yuk! Some linkers are smart enough to eliminate the redundancies at link time, but in general you can't be sure.
So the bottom line is:
it's best not to use inline virtual functions, since they're almost never expanded anyway. Even if your function is just one line, you're better off putting it in the module (.cpp file) along with the other class functions. Of course, programmers
often put short virtual functions in the class declarationâ"not because they expect the function to be expanded inline, but because it's more convenient and readable.
相关文章推荐
- Warning: array_merge() [function.array-merge]: Argument #2 is not an array in e\\class\\functions.php on line 2193
- Kotlin语法(十九)-内联函数(Inline Functions)
- Pure Virtual Functions and Abstract Classes in C++
- Inline Functions(内联函数)
- Think before you code, Virtual Functions in C++
- a missing vtable usually means the first non-inline virtual member function 问题
- Virtual functions in derived classes
- Think before you code, Virtual Functions in C++
- 消息 1033,级别 15 The ORDER BY clause is invalid in views, inline functions, derived tables, subqueries, and common table
- Inline Functions versus Macros
- Can static functions be virtual in C++?
- The relationship of inline and virtual
- How to use VirtualBox in Terminal / Command line
- Inline Functions in C++
- How do virtual functions work in C++?
- 内联函数(Inline Functions)
- A missing vtable usually means the first non-inline virtual member function has no definition
- NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
- why inline functions must be put in header files?
- Inline Functions(Chapter 9 of Thinking in C++)