visibility vs. accessibility of protected symbols

[Jonathan M Davis]

On Friday, February 17, 2012 09:03:32 Steven Schveighoffer wrote:
> On Mon, 13 Feb 2012 21:05:35 -0500, Jonathan M Davis <jmdavisProg at gmx.com>
> 
> 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.

I know. That's part of why I'm arguing that protected is enough and that 
private shouldn't be virtual. But pretty much the whole point of doing NVI 
with private is the theory that you want to guarantee that the derived classes 
can't call the function. The fact that you can't actually guarantee that just 
makes the arguments for making private virtual for NVI that much weaker.

But Timon's arguments make it sound like he doesn't understand what NVI is, 
which was the point of my post.

- Jonathan M Davis