The expenditure of the virtual function will mention the virtual function, first think of the polymorphism, then thinking is that overhead (at least I started, this is like this), where is the overhead of the virtual function? How big is overhead? In theory, the dynamic overhead brought about by virtual functions mainly depends on three aspects: compilers, operating systems, and machines. But in reality, almost all compilers operate in the same way. The overhead calling a virtual function is mainly from 2 aspects. One is if the virtual function is not inline, it will add some additional machine instructions, but generally add 3-5 machine instructions (it looks there. I don't know clearly, but this conclusion I remember very clearly), from time to time, more expensive than a non-virtual function, there are more than 10% -20% overhead, if there are several parameters, this ratio Will be smaller. At the same time, the connection overhead of the function call is usually only a small part of the total overhead, so basically, the overhead of the order function can be ignored. Of course, if you use a large amount of virtual functions in the program, it will naturally decline naturally, and there are fewer accumulation.
The timing sector function of the false preframework function can not be virtual, this problem is clear: Can! So when do you design a patriant function as a virtual? Beginners tend to make such a mistake: the base sectoral function should of course be a virtual! It seems that this rule is relatively easy to remember, of course, she also has her own theoretical basis (although the analysis is not comprehensive): Since a class can be used as a base class, then he intends to use the polymorphism, so the destructive function should be used. Set to virtual; additional virtual functions are implemented because most compilers use VTBL methods, and VTBL is a class shared, all of which share this vtbl, in other words, if a class is already A virtual function, then declare the destructor as a virtual function does not have any space overhead for each instance object. However, this analysis is still inaccurate, such as the example below Class Base {public: ~ base () {cout << "base!" << endl;}}
Class Derive: Public Base {public: ~ derive () {cout << "Derive!" << endl;}}; derive d; see if he call ~ base? Although Base is a base class, its destructive function does not need to be declared as virtual. So when is it necessary to declare a virtual? More accurate rules are as follows: If the derived class has a special destructor, and we also need to dynamically delete the base class pointer, then the destructor of this base class should be virtual.
The fictional creation function is since we have a false argument function, then there is no fictional function? Unfortunately, no! The reason is that the virtual call is a mechanism that works in an incomplete information of a given information. In particular, virtual allows us to call a function, for this function, only know its interface, and do not know the specific object type. But to create an object, you have to have full information. In particular, you need to know the specific type of object to be established. Therefore, the call to the constructor cannot be virtual. However, it is also able to give you a comfort, we can simulate the fictional manufacturing function. In TC PL Section 15.6.2. Section Bjarne Master gives an example. Inadvertently, the author of "Thinking In C " also gives a method of simulating the fiction function, which is basically like this. / / Give an abstract class Shape, there is an interface class shape {public: shape (); virtual ~ shape (); virtual void draw (); // ....}; class circle: public shape { Public: circle (); ~ circle (); void draw (); // ...};
Class Rectangle: Public Shape {public: Rectangle (); ~ Rectangle (); Void Draw (); // ...};
// to give a package at ShapeWrap class shapewarp {protected: shape * object; public: shapewrap (const string & type) {if (type == "circle") object = new circle; else if (type == "rectangle") Object = new rectangle; else {// ...}} ~ shapewrap () {delete object;} void draw () {Object-> Draw ();}}
Why is the member function not to virtual? Because many classes are not designed as base classes. For example, multiple classes. Moreover, an object containing a virtual function is to take up more space to implement a virtual function call mechanism - it is often a word that occupies a word (Word). This additional word is very considerable, and may cause trouble (eg C or Fortran languages) when compatibility involving data relating to other languages. To learn more of the design principles, you can refer to The D & E Of C .
Can the member function template can be Virtual? ANSI / ISO standards say (14.5.2 P 3): "A MEMBER FUNCTION TEMPLATE SHALL NOT BE VIRTUAL." (The template for a member function cannot be Virtual.)
