Re: Restricting access should be illegal?
Daniel James wrote:
In article
news:<1153146840.257909.293230@i42g2000cwa.googlegroups.com>,
Greg Herlihy wrote:
[...]
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();
You mean static_cast, I think. Reinterpret_cast has undefined
behavior here.
so I can see very little benefit in making B::Member private,
or in allowing it to be made so.
In Walter's example, that's true. As others have pointed out,
if the inheritance is private, static_cast will not allow you to
get the A*, so the function really is private. Except to
clients whom the B* has given an A*.
[...]
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).
Ideally, I'd like to distinguish between 1) functions which are
not virtual, 2) virtual functions which are at the bottom of the
hierarchy, i.e. that don't override anything, and 3) functions
which override a virtual function at a lower lever---in fact, in
3, it would also be nice to be able specify whether the function
can be further overriden or not. Obviously, because of history,
this can no longer be done. But even starting from scratch,
there is a question as to how much the added complexity costs as
opposed to the benefits of more precise specification.
--
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! ]