visibility vs. accessibility of protected symbols

[Andrei Alexandrescu]

On 2/17/12 8:03 AM, 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.
>
> -Steve

I agree. Walter and I chalked that up to a bug in TDPL that will be 
superseded by a different implementation.

Andrei