Accessibility of virtual functions

[Russco]

During a recent discussion on testing regimes I mentioned that on the whole I like to keep my virtuals non-public.

the relevant thread is :- http://www.codeguru.com/forum/showthread.php?t=469087

There is some discussion in that thread that relates to this one.

This is Herb Sutter's view on the subject :- http://www.gotw.ca/publications/mill18.htm

As you can see he recommends that you should generally set the interface to clients using non-virtual functions that kick down to non-public virtuals so that derived classes can customize behaviour. He feels that the public interface to client code and the interface to derived classes via virtual are distinct concerns. Virtual is for derived class implementors to customize behaviour and client code shouldn't be concerned when a method is called if that method is virtual or not, as long as the method does what its supposed to do the client code should be happy.

Here is the relevant chapter in Coding Standards that advises the same thing :- http://www.ubookcase.com/book/Addiso...3586/ch39.html

CPUWizard said that private virtuals make no sense in design and linked the C++ FAQ :- http://www.parashift.com/c++-faq-lit....html#faq-23.4

This particular FAQ has been the subject of some debates on comp.lang.c++.moderated

That's not misleading; it's completely wrong. I think there's
pretty much a consensus among the experts that most virtual
functions should be private---some experts have even gone to the
point of saying that they should always be private.
More than just citing a few experts who agree, I think it
interesting to note that until this FAQ entry, I'd never seen an
expert who disagreed. (Not everyone would go as far as Herb,
and say that virtual functions should never be public, but I
haven't seen anyone condemn the idiom per se.)

This FAQ suggests we should keep from using private virtual
function, because this usage will confuse the C++ newcomers.
I see the point here, but I can not agree.

Lets first limit the context to the language itself. It is now well-
known that class member should be private by default, here
member means both data member and function member.
Since virtual member belongs to function member, then the
virtual member should be private by default, unless in our
derived class the base version is required.

IIRC, Herb Sutter & Andrei Alexandrescu explained this issue
in their "C++ Coding Standards", also James Kanze (together
with other gurus) showed the same idea quite long time ago.
I agree with them on this point.

Another problem for that FAQ is, well, the suggestion/answer
is based on the assumption that new C++ programmers will
possibly fail to understand the language at the beginning.
I do not think this is a good reason because the above
assumption could be applied to quite a lot of places in C++
without any change. In my mind, trying to make all kinds
of mistaken/errors is the best way to master the C++
language, at least it works for me.

There appears to be 5 camps of thought on this.

It depends on what camp you are in. There have been extensive
discussions on this here, and people seem to be very divided about the
issue. I have identified at least five camps:
1. You can do what? You're kidding me!
2. Okay, I know you can do it, but no honest programmer would. It is
immoral and a disgrace to the profession.
3. You can do it, and you should because it is a great tool that helps
you to fine-tune access levels and maximize encapsulation. Make it
private in the base class and public in the derived class, or the
other way round, whatever meets your design needs.
4. Virtual functions should always be private, never public. Use
non-virtual public wrappers.
5. Virtual functions should always be protected, never public. This
camp is run and populated by James Kanze. <g>

I used to belong to camp 3, but I see the point of the camp 4 people.

Interestingly James Kanze has subsequently moved from camp 5 to camp 4.

This is Nathan Myers thoughts on the subject

Defining a public virtual function declares two interfaces,
a calling interface and a derivation interface. The two have
different purposes and are used by different code, and as the
system evolves those purposes may diverge. Defining a public
non-virtual and a protected virtual function improves modularity,
and reduces that problem.

Practically, as James Kanze notes, it allows you to add checks to
the non-virtual before it calls the virtual. It also allows you to
do other work in the base-class nonvirtual function that you didn't
think to specify derived implementations of the virtual interface
must do.

In other words, it provides a place to extend the semantics of the
public function without breaking the implementations of derived
classes that you don't own. Additional argument checking is one
example of that.

As was also noted, if the non-virtuals are also non-inline, then it
insulates calling code from the layout of the class, which is essential
in environments where release-to-releasse binary compatibility of
libraries is required.

Hence, it's a good idea for several reasons, all connected with
improving modularity.

So what do you guys make of all this?
Should virtual functions generally be nonpublic until the need is proven otherwise?
Should we make them all public unless we REALLY dont want client code to call them?
Should we reopen camp 5 now James Kanze has vacated the position?

What generally do you do with your virtuals?