What is the potential danger of reorienting a private function to the public?

Question

I just find out that overriding a private function to a public one from the base object is allowed in C ++, since Visual Studio gives 0 warnings. Is there a potential danger to this?

If not, what is the difference between declaring a virtual function in a private, protected, and public in a base object?

Answer 1

what's the difference between declaring a virtual function private, protected, and open in the base object?

The difference is that the virtual private function can only be called from the base class. This can be useful if the function is not part of the interface of the external class and is used only by the base class. So users call (some other) members of the base class, and that member calls a virtual function. For instance:

 class Base { virtual void stage1()=0; // derived classes override this virtual void stage2()=0; public: void run() { stage1(); stage2(); } // users call this }; 

---

In addition, there is a point of view that you should not make your virtual functions public at all, because the fact that they are virtual is an inner class and its subclasses, and users should not be aware of this. Rarely, the same function should be overridden and called from external code. This allows the base class to control which (virtual) functions can be called from a (non-virtual) public method, making it easier to maneuver.

See this Herb Sutter article for more details:

... each [publicly available] virtual function performs two tasks: it defines an interface because it is public ...; and it defines the implementation details, namely the internal custom behavior ... That a publicly accessible virtual function inherently has two significantly different jobs - this is a sign that it does not separate the problems, and that we should consider a different approach. What if we want to separate the interface specification from the implementation specification, custom behavior?

...

In general, prefer to make virtual functions of the base class private (or if you really should). This separates interface and implementation issues, which stabilizes interfaces and makes implementation decisions easier to change and reorganize later.

However, I cannot say if this is really widely used ...

Answer 2

Is there a potential danger to this?

I don’t think so because you are still very limited:

 class Base { private: virtual void foo(){} }; class Derived1 : public Base { public: virtual void foo(){ Base::foo(); } }; class Derived2 : public Base { public: virtual void foo(){} }; int main() { Derived1 d1; d1.foo(); //error Base * d2 = new Derived2(); d2->foo(); //error } 

So, at best, you can call the overloaded function (if it does not call the function from the base class from itself), but the function of the base class will still have the same visibility and will not be available.

Answer 3

When access visibility is changed by overriding in a derived class, the visibility of the base class does not change:

So using

 class Base { public: virtual ~Base() = default; protected: virtual void foo() = 0; }; class Derived : public Base { public: void foo() override {}; }; 

Then

 Derived d; Base& b = d; d.foo(); // valid b.foo(); // invalid 

Answer 4

If not, what is the difference between declaring a virtual function in a private, protected, and public in a base object?

It depends on how you access the function. The type of object / pointer used determines whether you can access this function.

 class Base { public: virtual void foo() {} }; class Derived : public Base { private: virtual void foo() {} }; int main() { Derived* dptr = new Derived; Base* bptr = dptr; dptr->foo(); // Can't use it. Derived::foo is private bptr->foo(); // Can use it. Base::foo is public. } 

Compiler post using g ++ 4.9.3.

 socc.cc: In function 'int main()': socc.cc:12:20: error: 'virtual void Derived::foo()' is private virtual void foo() {} ^ socc.cc:20:14: error: within this context dptr->foo(); // Can't use it. Derived::foo is private 

Answer 5

A virtual function is a tuning point for implementing a derived class. If it is private, then it is an extremely detailed implementation. By making it more accessible in a derived class, it reveals implementation details, with all that it entails. In particular, client code may depend on this detail, so the implementation cannot be easily changed. It may also be easier for the tode client to invoke the wrong paths than the originally intended interface, and it can produce results that are only valid in certain contexts, so that they are more fragile than the original interface.