Why would a virtual function be private?

Question

I just spotted this in some code:

class Foo {
[...]
private:
    virtual void Bar() = 0;
[...]
}

Does this have any purpose?

(I am trying to port some code from VS to G++, and this caught my attention)

Answer 1

It is a pure virtual function. Any final implementation that is dervied from "Foo" MUST implement the "Bar" function.

Answer 2

It makes the function pure virtual as opposed to virtual.

No implementation is provided by default and the intent is that the function implementation must be specified by an inheriting class. This can be overriden however.

You sometimes see complete classes where all member functions are specified as pure virtual in this manner.

These are Abstract Base Classes, sometimes referred to as Interface Classes, and the designer of the ABC is saying to you, "I have now idea how this functionality would be implemented for all specialisations of this base class. But, you must have all of these defined for your specialisation to work and you know how your object should behave".

Edit: Oops, just spotted the fact that the member pure virtual function is private. (Thanks Michael) This changes things slightly.

When this base class is inherited using private inheritance it changes things. Basically what the designer of the base class is doing is saying is that, when your derived class calls a non-private function in the base class. part of the behaviour has been delegated to your specialisation of the function in your derived class. The non-private member is doing "something" and part of that "something" is a call, via the pure virtual base class function, to your implementation.

So some public function in Foo is calling the Bar function inside Foo, and it is relying on the fact that you will provide a specialised implementation of the Bar function for your particular case.

Scott Meyers refers to this as "implemented in terms of".

BTW Just chuckling about the number of answers that were quickly deleted by people who also didn't see the "fine print" in the question! (-:

HTH

cheers,

Answer 3

See this Herb Sutter article as to why you'd want to do such a thing.

Answer 4

The only purpose it seems to serve is to provide a common interface.

BTW even though a function is declared as private virtual, it can still be implemented and called with the class instance or from friends.

Nonetheless, this sort of things usually meant to serve as interface, yet I don't do it this way.

Answer 5

I'm going to quote a brief explanation from the great C++ FAQ Lite which sums it up well:

[23.4] When should someone use private virtuals?

Almost never.

Protected virtuals are okay, but private virtuals are usually a net loss. Reason: private virtuals confuse new C++ programmers, and confusion increases cost, delays schedule, and degrades risk.

New C++ programmers get confused by private virtuals because they think a private virtual cannot be overridden. After all, a derived class cannot access members that are private in its base class so how, they ask, could it override a private virtual from its base class? There are explanations for the above, but that's academic. The real issue is that almost everyone gets confused the first time they run into private virtuals, and confusion is bad.

Unless there is a compelling reason to the contrary, avoid private virtuals.

Answer 6

The usual "academic" answer is: access specifiers and virtuality are orthogonal - one does not affect the other.

A little more practical answer: private virtual functions are often used to implement the Template Method design pattern. In languages that do not support private virtual functions, the template method needs to be public although it is not really meant to be a part of the interface.

Answer 7

ISO C++ 2003 explicitly allows it:

§10.3 states nothing about access specifier and contains even a footnote in the second clause stating in the context of virtual function overrides:

[...] Access control (clause 11) is not considered in determining overriding.

The code is fully legal.

Regards,
Ovanes