Java – need to declare virtual functions as such

cjavaobject-orientedvirtual-functions

Example:
We have a base class Base and three subclasses which all implement their own version of doSomething().

In an intermediate function f(Base b), we want to call the relevant version of doSomething() depending on which object has been passed.

Why do we need to declare doSomething as a virtual function in Base? Surely b now points to the correct object so that when we call b.doSomething, we know which method needs to be called.

Side Question: If b is simply pointing to an object, why does it even need a type?

Oddly enough, this once made perfect sense but I'm starting to have doubts, and questions are arising…

Best Answer

Because virtual functions have a runtime performance cost, and part of the philosophy of C++ is "you don't pay for what you don't use."

Specifically, virtual methods have to dereference a pointer to find out where the correct method is for the specific object they were called on. One pointer dereference per call may not sound like a lot, but this also prevents the function from ever being inlined, and you have to refer to the object itself via pointer or reference for a virtual function call to work in the first place (otherwise you get "object slicing" which may have wider repercussions).

Usually, this is indeed not a very big cost, which is why some languages like Java can get away with things like "making all class variables references" and "making all methods virtual by default", presumably in the hopes of creating a simpler language for applications that can be developed without a detailed understanding of how each language feature is typically implemented.

Side Question: If "b" is simply pointing to an object, why does it even need a type?

If you really want to, you can use void*, which is effectively a pointer with no type. But you shouldn't normally do that because properly typed pointers add a modicum of type safety. And most of the time, you should be using smart pointers like std::unique_ptr which are even safer since they automagically deallocate the memory they point to when you're done with them.

Related Solutions

Java – Why are inheritance and polymorphism so widely used

I mostly agree with you, but for fun I'll play Devil's Advocate. Explicit interfaces give a single place to look for an explicitly, formally specified contract, telling you what a type is supposed to do. This can be important when you're not the only developer on a project.

Furthermore, these explicit interfaces can be implemented more efficiently than duck typing. A virtual function call has barely more overhead than a normal function call, except that it can't be inlined. Duck typing has substantial overhead. C++-style structural typing (using templates) can generate huge amounts of object file bloat (since each instantiation is independent at the object file level) and doesn't work when you need polymorphism at runtime, not compile time.

Bottom line: I agree that Java-style inheritance and polymorphism can be a PITA and alternatives should be used more often, but it still has its advantages.

C++ – Is it possible to refactor inheritance to composition when virtual methods are called inside the base class

So let's make this concrete-ish.

class Country {
  virtual void foo();
  void bar() {
    foo();
  }
}

Moving toward:

class Country {
  private thingWhichWasSubclass;
  void bar() {
    thingWhichWasSubclass.foo();
  }
}

Is that right? How about as an intermediate step:

class Country {
  private thingWhichWasSubclass;
  void foo() {
    thingWhichWasSubclass.foo();
  }
  void bar() {
    foo();
  }
}

Would that do it? Then (of course) inline Country.foo().

Best Answer

Because virtual functions have a runtime performance cost, and part of the philosophy of C++ is "you don't pay for what you don't use."

Related Solutions

Java – Why are inheritance and polymorphism so widely used

C++ – Is it possible to refactor inheritance to composition when virtual methods are called inside the base class

Related Topic