Let's say we have codes like follow:
class Base{
public:
virtual ~Base(){PutStat();};
virtual void PutStat(){/* maybe do nothing */};
};
class Desend : public Base{
public:
void PutStat() override{/* do something */};
};
Method PutStat will print some statistic. I hope every instance of Descendants inherited from Base could automatically print a statistic message while destructing.
It seems like a common feature here to output stat-message, so I think it's more reasonable to call PutStat just once in Base than call PutStat in each descendants separately.
Unfortunately, as destructor in Base is virtual, thus un-overrided PutSat will be called.
So how to call the overrided version of PutStat in Base destructor.
Unfortunately, as destructor in Base is virtual, thus un-overrided PutSat will be called.
Correct, but not for that reason. The destructor being virtual has nothing to do with it. The base class's methods will be called because the object has been partially destroyed back to the base class, which includes causing its VFT be that of a base class instance.
How to call the overridden version
You can't. It's gone. The object has gone. It wouldn't make sense, so C++ doesn't allow it.
Related
Yes I have seen a lots of posts about using the keywords virtual and override for destructors in C++. I also think I understand the usage:
if a base class has a virtual destructor and a derived class overrides it, if the signatures are different, the program will not compile due to override.
However I am wondering - or I have seen it also several times in someones code, that it is used like this:
class Base
{
public:
~Base();
};
class Derived : public Base
{
public:
~Derived() override;
};
Does this override on a destructor of a non-virtual function in the base class actually has any impact on the program / compiling or anything? Or is it just used wrongly in that case?
You code doesn't compile because Base::~Base is not virtual.
Oh ok, maybe I have overseen this: if the Base class derives from
another class, say SuperBase class - which has a virtual destructor,
then the destructor of Base would be virtual without using the keyword
right?
Correct. If a method is virtual in a base class, then the method in the child class with the same name and same signature will also be implicitly virtual. virtual keyword can be omitted.
A good practice is to always use the keyword override on a method intended to override. This has two big advantages: it makes it clear to a human reader that the method is virtual and overrides and it avoid some bugs where the method is indented to override, but it silently doesn't (e.g. const mismatch).
Destructors are a special case in the sense that that they override a parent virtual destructor, even if they have different names.
Note: I am not asking why a parent class need to have virtual method.
I remember something coding guideline like that(I don't remember well and just try to express as my own word,hope I have correct wording): if the parent class have virtual method,the derived class should also at least have one virtual method, even the derived class would not have derived class from itself, if the derived class really no need to have any virtual method, set destructor as virtual. The reason behind it is something like "prevent duplicate virtual table", what is it talking about?
And I also remember a related example like that:
class A{
virtual f();
};
class B : public A{
};
B as no derived class, if B has no virtual method, the consequence is something like "any place that include B will have a duplicate virtual table generated by compiler" (also is just expressed from my impression), what is the meaning of that (if it is true)?
Note the following:
If the base class has a virtual member function other than a destructor, the derived class inherits that function.
If the base class declares a member function as virtual, and the derived class declares a member function of the same name with the same argument types, then the derived class function is automatically virtual, and overrides the base class's function.
If the base class has a virtual destructor, the derived class's destructor is automatically virtual, whether user-declared or not, and overrides the base class's destructor.
The example you gave is not in any way problematic. I would advise you to forget everything you think you remember about this coding standard.
I´m trying to accomplish the same which is described in a previous question:
virtual function call from base class
But, my real question is:
What if f() is the constructor in the Base class? Which g() will be called? I don´t know if I am doing wrong, but in my program it seems to be that is the opposite.
Taking the same variables from the previous question, a code which shows such
behavior would look like this:
Class Base
{
Base(){g();};
virtual void g(){//Do some Base related code;}
};
Class Derived : public Base
{
Derived(){};
virtual void g(){//Do some Derived related code};
};
int main()
{
Derived newDerived;
return 0;
}
Update:
Thanx to Naveen.
He provided me a page which contains all related information about this topic.
I´ll let you know the link here:
parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.6
Even though it's a virtual function, the base's version will get called since the derived class isn't fully constructed yet. The base class constructor is called before the derived class constructor, so if the derived virtual function were to get called, it would be with an incompletely-initialized instance - a possible (probably) recipe for disaster.
It will Base::g(). See this FAQ for explanation.
When your base class constructor is called, only the vtable for the base class is setup, so any virtual function calls will apply only to base class methods.
When the derived class constructor is called, calling a virtual function will call the derived class override, if any.
The virtual mechanism does not work in the constructors, so if you call even a virtual function from a base class constructor you will always end up calling the functions of the base class only. There are a few reasons why the virtual funcs do not work in the ctors:
While in the constructors the object has not been created fully.
ctors calls are resolved at compile time only, so they actually don't have any runtime dependency, so no use of virtual functions.
Unlike other functions ctors and dtors are not inherited, so every class has its own set of ctors and dtors, so there is no chance of overriding.
Starting to use PC-Lint on an existing code base (fear and trepidation).
One thing that it complains about is the following:
class IBatch
{
public:
virtual void StartBatch() =0;
virtual int CommitBatch() =0;
};
Which when another class derives from this to use it like an interface
base class 'IBatch' has no destructor
So, the question: when you create Interface classes like the above, do you always include a virtual destructor? Why? (is it a style or a coding error?)
EDIT: Should have said that I do not expect or want the user of IBatch to destruct, they are a consumer of a service only, through this interface to some external implementing class (if that would make a difference)
A base class destructor should be either public and virtual, or protected and nonvirtual.
(Herb Sutter, Guru of the Week #18: "Virtuality")
Coding error - The destructor for your derived class will never get called if called via pointer to base class.
When you implement IBatch and you refer to your derived class by a pointer to a base class (pointer to IBatch) and you call delete on that pointer to base class you might end up with memory leak because the destructor for your derived class will never get called.
The basic rule is when a class has at least one virtual method it needs to have virtual destructor.
class IBatch
{
public:
virtual void f() = 0;
};
class A : public IBatch
{
public:
void f() {}
~A() {}
};
IBatch * a = new A();
a->f(); // calls A::f()
delete a; // calls IBatch::~IBatch() not A::~A()
If there are virtual functions, there needs to be a virtual destructor. Always. It does not matter that it's only an interface class -- it still needs the virtual destructor.
Either that, or it needs a protected nonvirtual destructor. But then you cannot delete the object using the interface pointer.
A class with virtual functions but no virtual destructor is suspect, and most likely wrong: see a good and more precise explanation here.
So, the question: when you create
Interface classes like the above, do
you always include a virtual
destructor? Why? (is it a style or a
coding error?)
Well it depends really. If you ever call delete on an IBatch pointer it probably won't do what you are expecting. Of course if you have something like virtual Init/Shutdowns or AddRef/Releases then its not really a problem.
Compiler puts default destructor that is not virtual, which implies that a 'delete' on a pointer to the virtual base class will succeed with a resulting memory leak. Therefore, it is an implementation flaw, neither style or coding error.
Sorry if this is a dupe, I cant find an answer quite right.
I want to call a function from a base class member, and have it resolve to the subclass version. I thought declaring it virtual would do it, but it isn't. Here's my approach:
class GUIWindow
{
public:
GUIWindow()
{
SetupCallbacks();
}
virtual void SetupCallbacks()
{
// This function always called
}
};
class GUIListbox : public GUIWindow
{
public:
void SetupCallbacks()
{
// This never called
}
};
GUIListbox lb; // GUIWindow::SetupCallbacks is called :(
What am I doing wrong?
Many thanks
Si
Never call a virtual function in the constructor.
When you call virtual functions during construction of some class C (i.e. while the constructor of C is active), the virtual mechanism works, but it works in restricted mode. The resolution of the virtual calls in the class hierarchy is limited by the class that is currently being constructed (C). This means that the virtual calls will resolve as if the class C is the "final" class in the hierarchy, as if it has no descendants.
The same is true for destructors.
In your example, you are calling a virtual function from constructor of class GUIWindow. As long as the constructor of GUIWindow is active, its virtual mechanism will work as if there are no other classes derived from GUIWindow. This mechanism will completely ignore the existence of GUIListbox class. This is why the resolution of virtual call "stops" at GUIWindow and calls GUIWindow::SetupCallbacks, as if GUIListbox::SetupCallbacks doesn't exist.
You can read about in in C++ FAQ
http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.5
Your derived type is not constructed yet.
Class Cat : Animal
{
//...
};
When you create a create a Cat object the following happens:
Construct Animal
Construct Cat
When your object goes out of scope or gets destroyed via delete if on the heap, the following happens:
Destruct Cat
Destruct Animal
For this reason you should not call virtual functions in your constructor or destructor. You would even have a pure virtual function call if you did not have an implementation in your base class.
You are going to have to:
GUIListbox lb;
lb.SetupCallbacks();
The point of virtual is so that you can do things like:
GuiWindow *lb = new GuiListbox();
lb->SetupCallback();//Gets correctly resolved to GuiListBox's version
The problem is that you are trying to call the virtual function form the constructor. The base class constructor is called before the constructor of the derived class, so the "derived parts" of the object are not created yet when the base classes constructor runs.
The object will behave like an object of the base class type until the base classes constructor is finished and the derived classes constructor starts. This means that calls to virtual functions will not call implementations defined in the derived class, they will just execute the version from the base class.
Also see the C++ FAQ lite for more details and possible workarounds.
The quick answer is that you may have to declare a constructor in GUIListbox which calls SetupCallbacks. The reason is more complicated: because GUIListbox doesn't declare a constructor, when you declare an object of that type the GUIWindow constructor is called. When the GUIWindow constructor is running, the object isn't a GUIListbox yet. From the compiler's perspective, it only becomes a GUIListbox once the (empty) constructor for that class starts. So when the first constructor runs, the methods from GUIWindow are called. IOWs, this doesn't work, and will never work in C++ the way that you want it to.
Here's a reference describing this pitfall in detail: http://www.artima.com/cppsource/nevercall.html.
And here's an explanation from my favorite C++ resource: http://yosefk.com/c++fqa/inheritance-mother.html#fqa-23.5