How C + + handles inline virtual functions

http://blog.csdn.net/hedylin/article/details/1775556

When a function is an inline and virtual function, does code substitution occur or does it use a virtual table call? In order to figure out the inline and virtual functions, let's consider them separately. In general, an inline function is expanded.

        Class Cfoo {
        Private
            int Val;
        Public
        int Getval () {return val;}
        int setval (int v) {return val=v;}
        };        

Here, if you use the following code:

        Cfoo x;
        X.setval (17);
        int y = X.getval ();  

The compiler will then produce the same target code as the following code snippet:

        Cfoo x;
        X.val = 17;
        int y = x.val;  

Of course you can't do this, because Val is a private variable. The advantage of inline functions is that you can hide data without a function call, and that's all.

Virtual functions are polymorphic, meaning that derived classes can implement the same functions, but with different functions. Suppose Getval is declared as a virtual function, and you have a second class CFoo2 implemented in a different way:

        Class Cfoo2:public Cfoo {
        Public
        Virtual in base class Too!
        virtual int Cfoo2::getval () {return someotherval;}
        };

If Pfoo is a cfoo or CFoo2 pointer, the member function Cfoo can invoke success regardless of which class CFoo2 or pfoo->getval the Pfoo points to.

What happens if a function is both a virtual function and an inline function? Remember, there are two ways to build inline functions ,

The first is to use the keyword inline in a function definition, such as:

        Inline Cfoo::getval () {return val;}        

The second is to write the function body in the declaration of the class, just like the previous cfoo2::getval. So if you include a virtual function body in the declaration of a class, such as:

        Class Cfoo {
        Public
        virtual int getval () {return val;}
        };        

The compiler considers the function getval to be inline and virtual. So how does polymorphism and inline behavior work at the same time?

The first rule that the compiler follows is that polymorphism must work no matter what happens. If there is a pointer to the Cfoo object, Pfoo->getval is guaranteed to call the correct function. In general, this means that function Getval will be instantiated as non-inline functions and have vtable (virtual table) entries pointing to them. But this does not mean that the function cannot be extended! then look at the following code:

        Cfoo x;
        X.setval (17)
        int y = X.getval ()  

The compiler knows that X is Cfoo, not CFoo2, because the heap object is explicitly declared. X is definitely not CFoo2. So it is safe to expand the Setval/getval inline. If you want to write more complex code:

...

The compiler knows that Pfoo points to X for the first time and the second point to X2, so it is safe to expand the virtual functions.

You can also write more complex code where the object type that Pfoo refers to is always transparent, but most compilers do not do any more parsing. Even in the previous example, some compilers will run safely, instantiate and invoke through a virtual table.In fact, the compiler always ignores inline needs and always uses virtual tables. The only absolute rule is that the code must work, that is, the virtual function must have polymorphic behavior.
In general, whether explicit or implicit inline, it is just a hint, not a necessity, just like a register. The compiler can completely refuse to expand a non-virtual inline function, and the C + + compiler often starts with an error: "Inline interrupt-function too large". If an inline function calls itself, or if you pass its address somewhere, the compiler must produce a normal (out-of-band). function Inline functions are not expanded in debug builds and can be prevented by setting compilation options.
The only way to know what the compiler is doing is to look at the code it produces. For Microsoft compilers, you can use the-FA compilation option to generate a compilation list. You don't have to know how the assembler does it. I encourage you to complete the experiment, which is good for understanding what the machine actually does, and you can learn a lot from the assembly list.
Something about inline functions is much more complicated than when you first touch it. There are many kinds of situationsforcing the compiler to produce normal functions：recursive, get function address, too large of those functions and virtual function。 But if the compiler decides to instantiate your inline function, consider where you want to put the function. Which module does it enter?
The class is typically declared in a header file, so if a CPP contains foo.h and the compiler decides to instantiate Cfoo::getval, it is instantiated into a static function in the CPP file. If 10 modules contain foo.h, there are 10 virtual function copies generated by the compiler. In fact, virtual tables can be used to point to different types of getval copies, so that objects of the same type produce only copies. Some linker can skillfully exclude redundancy when linking, but generally you can't expect him to guarantee.
We came to the conclusion that:It is best not to use inline virtual functions, as they will hardly be expanded, even if your function has only one line, you'd better put it in the module (CPP file) along with other class functions.of course, developers often put short virtual functions in class declarations-not because they want the function to be expanded inline, but because it is easier and more readable。

How C + + handles inline virtual functions