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 > mind.
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