The differences between sub-classes in Java and C ++ on the accessibility reduction covered by parent-Class Functions

The differences between sub-classes in Java and C ++ on the accessibility reduction covered by parent-Class Functions

Preface

The question "the sub-classes in Java and C ++ have reduced the accessibility of the parent class function coverage" seems more academic, but it is indeed a problem that is easy to ignore. This article attempts to elaborate on the differences between Java and C ++.

First, we will introduce what is "Reducing the accessibility of sub-classes to cover parent-class functions ". For inheritance, subclasses can overwrite the "virtual functions" of the parent class. Although Java does not have a virtual function, all Java functions can be considered as virtual functions, because all Java functions can be overwritten by the quilt class. Here we only use the meaning of the term "virtual function" without going into the details of the language. Both Java and C ++ allow changing the accessibility of functions during overwriting. The so-called "accessibility" is to use access controllers such as public, protected, and private to control whether a function can be accessed. Generally, the order of accessibility is (because C ++ does not have the concept of a package, packet access control is not considered for the moment, which does not affect the discussion here ):

public > protected > private

Take Java as an example:

class Base { protected void sayHello() {  System.out.println("Hello in Base"); }}class Child extends Base { public void sayHello() {  System.out.println("Hello in Child"); }}

Note:HeresayHello() Function. In the Base of the parent class, this function is modified using the protected access controller. This does not cause any problems if the subclass changes to public. It is usually not a problem to extend the accessibility when the subclass overrides the parent class function.

Java and C ++ adopt different policies when subclasses reduce the accessibility of parent class functions.

Take Java as an example to see the following code:

class Base { public void sayHello() {  System.out.println("Hello in Base"); }}class Child extends Base { private void sayHello() {  System.out.println("Hello in Child"); }}

In the above Code, the highlighted 8th line has a compilation error-This Code cannot be compiled at all! Java does not allow sub-classes to narrow down the accessibility when overwriting the parent class function. We can use an example to explain the cause. For example, we write the following code outside the class:

Base base = new Base();base.sayHello();base = new Child();base.sayHello();

If the previous code can be compiled, there is a possibility that sayHello () can be accessed when the base points to new Base, however, when the base points to new Child (), sayHello () cannot be accessed! In Java, this is a contradiction and should be avoided. Therefore, from the compiler perspective, we cannot write the above Code.

For C ++, the situation is different. Let's look at the example of C ++:

class Base {public:  virtual void sayHello() {    std::cout << "Hello in Base";  }}class Child : public Base {private:  void sayHello() {    std::cout << "Hello in Child";  }}

This code is completely correct in C ++. Note that the sub-classes here reduce the accessibility when overwriting the parent class function. If you don't see the problem, you can write the following code outside the class:

Child child; child. sayHello (); // It cannot be compiled because sayHello () is a private static_cast <Base &> (child ). sayHello (); // It can be compiled because sayHello () is public

Row 2nd fails because in Child,sayHello()It is private and cannot be called externally. However, when we use static_cast to forcibly convert a Child to a Base object, things change-for the Base,sayHello()Is public, so it can be called normally.

To address this problem, the access to virtual functions section in the C ++ standard Member Access control chapter can be found as follows:

class B {public:  virtual int f();};class D : public B {private:  int f();};void f() {  D d;  B* pb = &d;  D* pd = &d;  pb->f(); // OK: B::f() is public, D::f() is invoked  pd->f(); // error: D::f() is private}

The C ++ standard provides the following explanation:

Access is checked at the call point using the type of the expression used to denote the object for which the member function is called (B * in the example above ). the access of the member function in the class in which it was defined (D in the example above) is in general not known.

There are two key points for simple translation:

• Access control is checked during calling. That is to say, whoever calls this function checks whether anyone can access this function.
• The accessibility of member functions in the class is generally unknown. That is to say, when you check the accessibility, you cannot know whether the function is public or private during definition, therefore, the accessibility cannot be checked accordingly.

For this reason, the C ++ caller seems to be able to use some technical conversions to "cleverly" Call functions that were originally inaccessible. A more practical example is: In Qt,QObject::event()The function is public, and its subclass QWidget'sevent() The function is changed to protected. For more information, see the Qt code.

To sum up, Java strictly limits the sub-class's ability to narrow down function accessibility when the sub-class overrides the parent class function, but C ++ does not. In my opinion, from the perspective of software engineering, Java regulations undoubtedly have more engineering significance and function calls are more consistent. The C ++ standard will obviously simplify the compiler implementation, but it is not a good reference for the project.

PS:The C ++ standard official version needs to be purchased, but the draft can be downloaded for free. C ++ draft standards can be found on the following page: https://isocpp.org/std/the-standard

Summary

The above is all the content of this article. I hope the content of this article has some reference and learning value for everyone's learning or work. If you have any questions, please leave a message to us, thank you for your support.