Re: Private implementation of public pure virtual
Jiang wrote:
Alf P. Steinbach wrote:
* Jiang:
{ See the FAQ item "When should someone use private
virtuals?" currently at <url:
http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.4>.
-mod }
Sorry but the above faq has litte to do with the OP's problem,
It concerns the very same issue. Access specifiers and
virtuality (the ability to override) are orthogonal
features: one does not affect the other, at the technical
level. The issue is then how these features can or should
be meaningfully mixed at the design level.
Yes, what you said is true and really important in my mind,
but it seems that this is not what Tarjei really want.
The OP's problem is, well, whether the access specifier "overriding"
in derived class should be valid or not. Actually I do not think
Tarjei was confused by private virtual function overriding, at least
for his OP's context.
and also IMHO that faq is quite misleading.
Could you please elaborate on that, so that the FAQ could be improved?
That faq says:
[quote C++ FAQ Lite]
[23.4] When should someone use private virtuals? New!
Almost never.
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.
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
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. Private, in C++, does
not mean the same thing as private in Java, and if a beginning
programmer doesn't realize this, he's going to have problems
with overload resolution, amongst other things, and not just
overloading private virtual functions. (In fact, of course, as
soon as he sees a private virtual function, he will realize that
his understanding was wrong; if you couldn't override private
virtual functions, it would be illegal to declare a private
function virtual.)
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.
The compelling reason is programming by contract. And the fact
that it is a more or less standard idiom in C++.
[end quote C++ FAQ Lite]
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.
The idea of avoiding special features that a beginner might not
be familiar with is a good one, in itself. But you must bring
beginning C++ programmers up to speed with the standard idioms;
we don't create special iterators and avoid the STL simply
because beginners aren't familiar with using two iterators, and
are easily confused by it. And in this case, the issue concerns
a basic language element, which affects many, many aspects of
the code: private, in C++ does NOT mean what private means in
Java, and you must teach beginners what it really means, because
otherwise, they are going to be confused by many other things as
well, such as function overloading.
One can argue that the way C++ has defined certain things is
counter-intuitive. That may be (although in this particular
case, I think that the C++ solution is preferrable to the Java
one, even if it is less intuitive). But that's the way C++ is.
It's not part of the language that you can sweep under the table
and ignore. That's not true for everything, and I don't think
a beginner has to understand all of the subtilities of overload
resolution, for example, to be effective. But in this case, all
things considered, I think that the "counter-intuitive" meaning
of private in C++ is something that a beginner will not be able
to avoid.
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.
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.)
--
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! ]