Broken?

[Steven Schveighoffer]

On Wed, 12 Mar 2014 09:45:22 -0400, monarch_dodra <monarchdodra at gmail.com>  
wrote:

> On Wednesday, 12 March 2014 at 13:22:34 UTC, Steven Schveighoffer wrote:
>> OK, I can see that being useful. You are right, I was thinking C++  
>> private.
>>
>> -Steve
>
> Even in C++, private virtual a key part of the "non-virtual interface"  
> thing.
>
> EG: You define your base class as having only non-virtual public  
> functions, and private virtual function. They are private, so the  
> derived classes can't *call* them, but they can still override them.

Nonsense. If I'm writing a function, I can call it. There is no way to  
prevent it. e.g.:

class X
{
    virtual void _foo() {/* default impl */}
public:
    void foo() {_foo();}
}

class Y : public X
{
    virtual void _foo() {_foo2();}
    void _foo2() { /* do whatever I want here */}
}

OK, so your idea is that I can't call my copy of _foo, which if that's how  
it works, is dumb in my opinion. But if that's the case, I'm in control of  
its implementation, I can just forward to another function that I can call.

> The idea is that the base class holds any "non-modifyable" behavior, and  
> the virtual functions are only "customizeable sub-part behavior".
>
> For example, C++ streams work that way: All the public functions are  
> non-virtual. To create your own streams, you are supposed to only  
> override a set of low level functions, and then the base class takes  
> care of calling them correctly.

The idea is fine, but protected serves this purpose just as well.

-Steve