On 2/17/12 8:03 AM, 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.
-Steve
I agree. Walter and I chalked that up to a bug in TDPL that will be
superseded by a different implementation.
Andrei
