visibility vs. accessibility of protected symbols

[Steven Schveighoffer]

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.

-Steve