Interview Questions

Quote:

---

Originally Posted by OReubens

1) Performance is a secondary issue.

2) Code that works is the more important issue.

3) Adding virtual anywhere "just in case" is thus the better strategy.

---

Your logic is wrong. I agree with 1 and 2, but 3 is in direct conflict with 2.

By making all your methods virtual, you are allowing users to "hijack" them by over-riding them. Once you have "published" your class, you will not be able to maintain it anymore, as you'll have absolutely no idea how a third party user may have re-interpreted your function. At this point, changing anything in your code will potentially break your client's code, and I can guarantee you they'll hate that more than anything else.

Ignoring performance, the easiest way to write code that works is to write code that is closed and simple. Polymorphism is an open concept, and is not simple.

Quote:

---

Originally Posted by OReubens

But in this particular instance. We're talking about a performance lost of 5 sec over 500million iterations.
Yes, it's 5sec difference. but with an example that's tailored into forcing a bad result.
5sec lost over 500million iterations is "negligeable" most of the time.

---

Don't take this the wrong way, but hat really makes me wonder what kind of software you develop.

Quote:

---

Originally Posted by OReubens

Performance is a secondary issue. Your users are not going to love you if you make the fastest possible code that crashes. Or makes their machine go wonky.
Code that works is the more important issue.

Adding virtual anywhere "just in case" is thus the better strategy.

---

If I take a working application or library and start making all kinds of non-virtual member functions (or even just destructors) virtual that doesn't make make the code work any better. If a library user derives from a class with a non-virtual destructor and deletes a pointer to the base class, then the user's code is wrong.
I agree with laserlight that if you design a class library, you should make the intent clear. If your intention is that a class is not derived from then don't make the destructor virtual. If your intention is for a class to be used polymorphically, then make the destructor virtual, just in case a user wants to be able to safely delete a pointer to the base class.

Quote:

---

Originally Posted by OReubens

And you too seem to imply a relation to the class having other virtual functions. Again, THIS IS NOT what decides the need for a virtual destructor.

---

I don't think it makes much sense to talk about the need for a virtual destructor, because this depends on the code path that is taken at runtime. If a certain code path is never taken (perhaps just because the required input is never actually used) then strictly speaking there is no need for that code path to prevent runtime errors.

We are talking here about guidelines. I find the guideline to add a virtual destructor to any base class that has virtual methods a good one, because (1) if the class is designed to be used polymorphically (indicated by the virtual functions) that it is not unlikely that at some point a pointer to the base class should be deleted and (2) if the class has no virtual functions then I don't see a reason to store a pointer to this class, which points to a newed instance of a derived class. The only reason I can think of would be to store different types of objects in a single container, which can be achieved better using something like boost::variant or boost::any. If you have any more convincing use cases in mind, I'd be interested to hear them.