Re: Private implementation of public pure virtual
Herb Sutter wrote:
"kanze" <kanze@gabi-soft.fr> wrote:
[quote C++ FAQ Lite]
[23.4] When should someone use private virtuals? New!
Almost never.
That's not misleading; it's completely wrong.
Eek, yes.
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.
I'm in the "private by default" camp, but there are some
experts who disagree.
I'm not sure about "default": I find that my virtual functions
are private more often than not (more than, say, 80% of the
time), but I do give each case individual consideration. (To
me, default suggests that you don't even think about it unless
some unspecified set of external conditions are present to make
you think about it.)
Public virtual is fine, especially for
ABCs (interfaces), but in other kinds of classes the
programmer ought to understand that "public" and "virtual" are
two separate responsibilities, and why/what they are.
Even ABC's have contracts:-). IMHO, anytime there is a
contract, virtual functions should be private.
The typical case where they aren't private is in cases of
inversion of control---where the callee has been told by the
owner of the function being called to call it. In such cases,
there's not normally a contract with regards to the callee; he
doesn't call the function because he wants something done.
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
It's strange that I've never encountered this problem among new
C++ programmers. It's a question of education, but there's
really not the slightest ambiguity here.
Actually, I encounter this almost every time explain "private
virtual."
Maybe you're explaining it too soon:-). I find that programmers
seem to hit the barrier on overload resolution, before they even
try virtual functions. The fact that a private function
participates in overload resolution surprises. But once they've
understood that, and why it is so, private virtual doesn't seem
to introduce any additional surprises.
This does surprise new programmers. However, in my experience
once you explain it and point out that the accessibility label
is only about who may call the funtion, they immediately say
"oh" and then never ask again.
Yes. And the problem is more complex with regards to overload
resolution, because the private isn't taken into account there,
either, even though the function is being called.
Of course, Java and C# do it the other way, and lots of people
find that intuitive.
The importance is consistency. Java says that private basically
means invisible; it's consistant about it, and so it's more or
less intuitive. C++ says that private means not callable. And
it's sort of counter-intuitive that the function still
participates in overload resolution.
Unless there is a compelling reason to the contrary, avoid
private virtuals.
The compelling reason is programming by contract. And the fact
that it is a more or less standard idiom in C++.
Yes. Note that almost all virtual functions in the C++
standard library are not public (IMO they should be private,
but that's either a design preference or a historical
artifact).
Probably historical. I know that I was in the protected camp
for a long time. In the end, however, I've come to feel that
when designing a class, there's simply not that much difference
between protected and public. Both need a full, rigorous
contract, which in turn means non-virtual.
(Not everyone would go as far as Herb,
and say that virtual functions should never be public,
Small correction: I never said "never." I variously wrote
"prefer" or "consider" making them private by default.
Correction acknowledged. (The problem is that your name is
associated with the idiom, so it ends up being thought of as
"Herb's way of doing things", even if it is a way you only use
in specific cases.)
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]