non virtual interfaces

[Jonathan M Davis]

On Friday, September 20, 2013 22:40:48 Alexandr Druzhinin wrote:
> 20.09.2013 12:45, Ali Çehreli пишет:
> > On 09/19/2013 10:31 PM, Alexandr Druzhinin wrote:
> >  > if I use protected instead of private in interface like:
> > private member functions are non-virtual.
> 
> But I just use code example from TDPL russian edition. And TDPL says
> clearly that (un)transmogrify() are private and CardboardBox _maynot_
> make (un)transmogrify() non-private - this is highlighted as compiler
> support of NVI idiom. Is it wrong example, I guess?

TDPL is mostly correct but not completely correct. AFAIK, it has never been 
implemented that you can override private functions in interfaces like TDPL 
describes. With classes, package and private are _never_ virtual, so private 
will have be treated differently interfaces in order to do what TDPL describes. 
That may or may not be implemented in the future.

You can use NVI with classes just fine just so long as you use protected rather 
than private, but making it private there won't work either, because private 
is never virtual (and it wouldn't really help you any if it were, because 
while the base class private function might not be callable, the derived class 
one would still be callable by the derived class, so trying to prevent the 
virtual function in NVI from ever being called outside of the base class is 
broken in the first place - including in C++ where it was originally devised). 
What NVI helps with is making it so that the public function being called as 
part of the API is non-virtual, allowing you to do stuff before and after the 
hidden virtual function being called, but the derived classes can still call 
their implementation of the hidden, virtual function.

- Jonathan M Davis