On 02/14/2012 03:54 AM, Jonathan M Davis wrote:
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
The main difference is that C++ has an explicit 'virtual' modifier that
naturally grants override-access to private symbols.
