Re: Restricting access should be illegal?
In article news:<1153146840.257909.293230@i42g2000cwa.googlegroups.com>,
Greg Herlihy wrote:
Shouldn't restricting access to an overriding virtual function be an
error?
No, because there is a difference between invoking a method and
executing a method.
That's a pretty fine distinction -- and one that many users find confusing.
I'm not sure that it is helpful to make that distinction at all ...
Access levels can prohibit the invocation of a class method outside of
certain program contexts - but they have nothing to do with prohibiting
a method's execution at all.
No, indeed. In Walter's example there's nothing to stop the client making
the call as
reinterpret_cast<A*>(b)->Member();
so I can see very little benefit in making B::Member private, or in
allowing it to be made so.
If the intention is to enforce a polymorphic interface callable only*
through the base class there are more rigid ways of doing so:
-----------------------
#include <stdio.h>
class A {
public:
void Member() { DoMemberStuff(); }
private:
virtual void DoMemberStuff() { printf("A::DoMemberStuff\n"); }
};
class B : public A {
private:
virtual void DoMemberStuff() { printf("B::DoMemberStuff\n"); }
};
int main()
{
A *a = new A();
a->Member(); // OK, A::Member calls A::DoMemberStuff
B *b = new B();
b->Member(); // OK, A::Member calls B::DoMemberStuff
A *a2 = b;
a2->Member(); // OK, A::Member calls B::DoMemberStuff
}
-------------------------
Now there is no confusion. The public interface in A is public and can be
called with the desired effect on objects of either type A or type B; the
internal implementation is polymorphic because DoMemberStuff is virtual,
and is private (in both classes) which is both appropriate and consistent.
I can't immediately think of any reason not to do it this way, in real code
(I realize that Walter's snippet was just an example to expose this quirk
of the language).
The example program above shows nothing more than this method
invocation vs. execution distinction. The program contrives to execute
B::Member but does not do so by invoking B::Member itself. And while it
may not make much sense to use access levels in this manner, there is
no reason to make this use illegal - since nothing about the program
should be surprising.
I would say that the thing that most often surprises people is that marking
a virtual function private does not make it private in any real sense if it
is marked public elsewhere. It seems a pretty reasonable idea to make this
illegal (though I'm not sure it's worth the angst and upheaval of a
language change).
While we're on the subject: in Walter's example B::Member does not need to
be marked virtual -- it is implicitly virtual because it overrides a
virtual function in A. This can also cause confusion in much the same way
as differences in public/private declaration: people declare what they
think is a non-virtual function that is in fact virtual because it
overrides a virtual function in the parent class. I would favour requiring
the declaration of the override in the derived class to explicitly match
the declaration of the parent function that it overrides in terms of
virtualness and access type (public/private/protected).
--
Daniel James | djng
Sonadata Limited | at sonadata
UK | dot co dot uk
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]