visibility vs. accessibility of protected symbols
Jonathan M Davis
jmdavisProg at gmx.com
Mon Feb 13 18:54:18 PST 2012
On Tuesday, February 14, 2012 03:45:54 Timon Gehr wrote:
> On 02/14/2012 03:05 AM, Jonathan M Davis wrote:
> > On Tuesday, February 14, 2012 02:43:29 Timon Gehr wrote:
> >> On 02/14/2012 02:16 AM, Jonathan M Davis wrote:
> >> Well, not being able override what cannot be accesses is a quite basic
> >> requirement of security. Private members cannot be overriden in a
> >> different module.
> > Have you ever read up on NVI? That's how it's supposed to work. The whole
> > idea is to have derived classes override functions without being able to
> > use them. It makes it so that the public function is non-virtual and
> > contains whatever stuff you want to guarantee is called before or after
> > the private function, which is then virtual.
> > http://www.gotw.ca/publications/mill18.htm
> That article uses C++. It is not really a fair comparison, because in D
> there is no way to explicitly declare a method "private virtual", and
> D's private is different from C++'s private, and C++ has a different
> sub-typing and inheritance model. I think there are different design
> trade-offs at play.
> But I can make better sense of your point of view now: When I was
> talking about virtual I meant just a function that has an entry in a
> vtbl and is invoked virtually, while you probably had C++'s semantics in
I'm not aware of _any_ difference between virtual functions in C++ and D except
for the fact that all public and protected member functions are always virtual
in D (unless the compiler is able to determine that it can make them non-
virtual), and currently private and protected functions are never virtual.
What differences are you referring to?
- Jonathan M Davis
More information about the Digitalmars-d