On Friday, 17 February 2012 at 18:35:38 UTC, Jonathan M Davis
wrote:
On Friday, February 17, 2012 09:03:32 Steven Schveighoffer
wrote:
On Mon, 13 Feb 2012 21:05:35 -0500, Jonathan M Davis
<jmdavisp...@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
I understand what NVI is. It is just that private methods
overridable from a different module don't have many merits,
regardless of how NVI is apparently sometimes implemented in C++.
The fact that C++ has overridable private methods is quite likely
just a side-effect of wanting to give some kind of semantics to a
method declared as both private and virtual. I could argue that
it sounds like you don't understand what NVI is because you
assume C++'s private virtual semantics are required for the
implementation of NVI. ;)
As far as information hiding design goes, we certainly don't want
to borrow heavily from C++. Its system is unsound.
