Why should I mark all methods virtual in C++? Is there a trade-off?

Question

I know why and how virtual methods work, and most of the time people tell me I should always mark a method virtual, but, I don't understand why if I'm not going to override it. And I also know there's a tiny memory issue.

Please explain me why I should mark all methods virtual and what's the trade-off.

Code example:

class Point
{
   int x, y;
   public:
      virtual void setX(int i);
      virtual void setY(int i);
};

(That question is not equal to Should I mark all methods virtual? because I want to know the trade-off and because the programming language in the case is C++, not C#)

OBS: I'm sorry if there's any grammar error, English is not my native language.

Answer 1

(Edit - I got to this question by way of a duplicate C# question, but the answer is still useful, I think! Edited to reflect that:)

Actually, C# has a good "official" reason: https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/versioning-with-the-override-and-new-keywords

The first sentence there is:

The C# language is designed so that versioning between base and derived classes in different libraries can evolve and maintain backward compatibility.

So if you're writing a class and it's possible end-users will make derived classes, and it's possible different versions will get out of sync...all of a sudden it starts to be important. If you have carefully protected core aspects of your code, then if you update things, people can still use the old derived class (hopefully).

On the other hand, if you are okay with no one being able to used derived classes until their authors have updated to your newest version, everything can be virtual. I have seen this scenario in several "early access" games that allow modding - when the game version increases, all of a sudden a lot of mods are broken because they relied on things working one way...and they changed. (Okay, not all changes are related to this, but some are.)

It really depends on your usage scenario. If people can keep using your old version, maybe they don't care if you've updated it and are happy to keep using it with their derived classes. In a large business scenario, making everything virtual may very well be a recipe for breaking many things at once when someone updates something.

Does this apply to C++ as well? I don't see why not - C++ is also used for massive projects and would also face the dangers of multiple simultaneous versions.

Answer 2

It is not true that all functions should be marked as virtual.

Indeed, there's a pattern for enforcing pre/postconditions which explicitly requires that public members are not virtual. It works as follows:

class Whatever
{
public:
  int frobnicate(int);
protected:
  virtual int do_frobnicate(int);
};

int Whatever::frobnicate(int x)
{
  check_preconditions(x);
  int result = do_frobnicate(x);
  check_postconditions(x, result);
  return result;
}

Since derived classes cannot override the public function, they cannot remove the pre/postcondition checks. They can, however, override the protected do_frobnicate which does the actual work.

Answer 3

The real reason to make member functions non-virtual is to enforce class invariants.

Advice to make all member functions virtual generally means that either:

1. The people giving the advice don't understand the class, or
2. the people giving the advice don't understand OO design.

Yes, there are a few cases (e.g., some abstract base classes, where the only class invariant is the existence of specific functions) in which all the functions should be virtual. Those are the exception though. In most classes, virtual functions should be restricted to those that you really intend to allow derived classes to provide new/different behavior.

As for the discussion of things like vtables and the overhead of virtual function calls, I'd say they're correct as far as they go, but they miss the really big point. Whether a particular function should or shouldn't be virtual is primarily a question of class design and only secondarily a question of function call overhead. The two don't do the same thing, so trying to compare overhead rarely makes sense.

Answer 4

One of C++'s basic principles is that you don't pay for what you don't need. virtual functions cost more than normal member functions in both time and space. Therefore you shouldn't always use them irregardless of whether or not you'll actually ever need them or not.

Answer 5

Making methods virtual has slight costs (more code, more complexity, larger binaries, slower method calls), and if the class is not inherited from it brings no benefit. Classes need to be designed for inheritance, otherwise inheriting from them is just begging to shoot yourself in the foot. So no, you should not always make every method virtual. The people who tell you this are probably just too inheritance-happy.

Answer 6

That is not the case, ie, if you dont need a virtual function then dont use it. Also as per Bjarne Stroustrup Pay per use

In C++: --

1. Virtual functions have a slight performance penalty. Normally it is too small to make any difference but in a tight loop it might be significant.

2. A virtual function increases the size of each object by one pointer. Again this is typically insignificant, but if you create millions of small objects it could be a factor.

3. Classes with virtual functions are generally meant to be inherited from. The derived classes may replace some, all or none of the virtual functions. This can create additional complexity and complexity is the programmers mortal enemy. For example, a derived class may poorly implement a virtual function. This may break a part of the base class that relies on the virtual function.

Answer 7

No, you should not "mark all methods as virtual".

If you want the method to be virtual, then mark it as such. If not, leave the keyword out.

There is an overhead for virtual methods compared to regular ones. If you want to read more about this, check out the Wikipedia side about VTables.