Is there any reason for private virtual functions?

[Jimmy]

I was browsing the C++ FAQ Lite the other day when I came accross
question #23.4
(http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.4).
The question was "When should someone use private virtuals?", and the
author answered with "almost never, but there are reasons". So, I am
asking, what are the reasons. It seems illogical to have one; the
point of a virtual function is to be overriden in a derived class, and
the derived class cannot touch anything that is private in the base
class. Has anyone ever used a private virtual function before?

 

[Tom Widmer]

I was browsing the C++ FAQ Lite the other day when I came accross
question #23.4
(http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.4).
The question was "When should someone use private virtuals?", and the
author answered with "almost never, but there are reasons". So, I am
asking, what are the reasons. It seems illogical to have one; the
point of a virtual function is to be overriden in a derived class, and
the derived class cannot touch anything that is private in the base
class. Has anyone ever used a private virtual function before?

You use private virtual functions when you don't want anyone (including
derived classes) to call the function directly (which should be most of
the time, in a good, flexible design). You might use them when
implementing the "Template Method" pattern.

Some people recommend that virtual functions should be private by
default, and only protected and public if you have good reason. e.g.
http://www.gotw.ca/publications/mill18.htm

Tom

 

[Rolf Magnus]

I was browsing the C++ FAQ Lite the other day when I came accross
question #23.4
(http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.4).
The question was "When should someone use private virtuals?", and the
author answered with "almost never, but there are reasons".

Hmm, I have read documents that rather say something like "almost always,
but there are reasons not to".

So, I am asking, what are the reasons. It seems illogical to have one;
the point of a virtual function is to be overriden in a derived class, and
the derived class cannot touch anything that is private in the base
class.

It can't call it, but it can still override it. It seems to be a common
misconception that to override a function, it must be accessible.

Has anyone ever used a private virtual function before?

Yes. The basic idea is that the base class can check pre- and postconditions
and do other stuff that must always be done when the function is called. To
ensure that the virtual funtion is always called through the wrapper and
not directly, you make it private.
So you do something like:

class Base
{
public:
void foo(int i)
{
if (i > 1234)
throw std::range_error("greater than 1234");
do_foo(i);
}

private:
virtual void do_foo(int i) = 0;
};

class Derived : public Base
{
private:
virtual void do_foo(int i)
{
// i is never > 1234 here
}
};

 

[John Carson]

I was browsing the C++ FAQ Lite the other day when I came accross
question #23.4
(http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.4).
The question was "When should someone use private virtuals?", and the
author answered with "almost never, but there are reasons". So, I am
asking, what are the reasons. It seems illogical to have one; the
point of a virtual function is to be overriden in a derived class, and
the derived class cannot touch anything that is private in the base
class. Has anyone ever used a private virtual function before?

To override a virtual function, it is not necessary to have access to it.
Consider the following:

#include <iostream>
using namespace std;

class Base
{
public:
void Print()
{
PrintImplementation();
}
private:
virtual void PrintImplementation()
{
cout << "Base\n";
}
};

class Derived : public Base
{
private:
virtual void PrintImplementation()
{
cout << "Derived\n";
}
};


int main()
{
Base b;
Derived d;
Base * ptr0 = &b;
Base * ptr1 = &d;
ptr0->Print();
ptr1->Print();


return 0;
}


This model of public non-virtual functions and non-public virtual functions
is recommended by Sutter and Alexandrescu (C++ Coding Standards) in some
cases.

The idea is that the public non-virtual function provides an unchanging
interface, whereas the non-public virtual function provides an
implementation that can change as needed. Thus you could increase the number
of arguments of the virtual function without altering the class interface.
You can also have the public non-virtual function call multiple virtual
functions and derived classes can be selective in what they override.