On Mon, 13 Feb 2012 21:05:35 -0500, Jonathan M Davis <[email protected]>
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
This does nothing to protect the implementation. You are deluding
yourself if you think you can stop a derived class from calling it's own
implementation! In this case, protected is good enough, and I like how
private is always non-virtual. As Timon says, it's good for security and
module encapsulation.
-Steve
