Nature of C ++ programming criticism series inheritance

The essence of C ++ programming criticism series inheritance-general Linux technology-Linux programming and kernel information. The following is a detailed description. Both Eifel and C ++ provide multi-inheritance mechanisms. But Java does not, because it thinks that multi-inheritance will lead to many problems. However, Java provides interfaces as a replacement mechanism, which is similar to the protocol in Objective C ). Sun claims that the interface can provide all the features provided by multi-inheritance.

Sun's claim that "Multi-inheritance will bring about many problems" is true. This is especially true for the methods used to implement multi-inheritance in C ++. The reasons that seem to be easier to use multi-inheritance than single-inheritance prove meaningless now. For example, how can we develop policies for data items with the same name inherited from two classes? Are they compatible? If so, should they be merged into an entity? If they are not compatible, how should they be differentiated ?...... Such a list can be long and long.

Java's interface mechanism can also be used to implement multi-inheritance, but it also has a very important difference (compared with C ++): The interfaces in inheritance must be abstract. Because the interface does not have any implementation, this eliminates the possibility of selecting from different implementations. Java allows declarations of fields with constants in interfaces. When more inheritance is required, they are merged into an entity, which will not lead to ambiguity. But what happens when these constants have different values?

Because Java does not support multi-inheritance, we cannot use mixin as in C ++ and Eiffel. Hybrid is a feature that combines different non-Abstract functions from different classes to form a new complex class. For example, we may want to import some utility functions from different source codes. However, we can achieve the same effect by using combinations rather than inheritance. Therefore, this will not constitute an important attack to Java.

Eiffel does not import a separate interface mechanism to solve the problem of multi-inheritance.

Some may think that single inheritance is more elegant than multi-inheritance. This is a special point of view.

BETA [Madsen 93] is the one that thinks "Multi-inheritance is not elegant": "There is no multi-inheritance in Beta, mainly because (for multi-inheritance) there is a lack of profound theoretical understanding, and the current (for multi-inheritance) recommendations are technically complex ". They cited Flavors (a language that can combine classes) as evidence. Compared with Madsen, multi-inheritance in Flavors is related to its sequence. That is to say, inheritance from (A, B) is different from inheritance from (B,.

Ada95 is another language that does not support multi-inheritance. Ada95 supports single inheritance and is called tagged type extension ).

Others believe that many inheritance issues under some special models can provide elegant solutions, so the effort is worthwhile. Although the list of Multi-inheritance issues listed above is not complete, it still shows that problems related to multi-inheritance can be identified by the system. Once the problem is confirmed, they can also be elegantly solved. When the [Sakkinen 92] Study on Multi-inheritance reaches a deep level, it comes to the above definition.

The method used in Eifel is that multi-inheritance can lead to interesting and challenging problems and then solve them elegantly. All the decisions that the programmer needs to make are restricted in the inheritance clause of the class. It includes the use of renaming to ensure that many features with the same name from the inheritance will eventually become features with different names. The new export policies for inherited features are redefining and undefining, and select used to eliminate ambiguity. In all circumstances, the compiler will do all this for us. To make the semantics clear, programmers have full control over whether they choose to use fork or join.

Compared with Eiffel, C ++ has another different mechanism for eliminating ambiguity. In the Eiffel clause, features must have different names. In C ++, the domain resolution operator ':' can be used to differentiate members. The benefit of Eifel is that ambiguity is eliminated in the Declaration. The inheritance clause of Eiffel is much more complex than that of C ++, but its code is simpler, more stable, and more flexible. This is the benefit of declaring a method over an operator method. In C ++, every time we encounter ambiguity between multiple members, we must use the domain resolution operator in the code. This makes the code messy and affects its scalability. If changes in other places affect ambiguity, we may need to change the existing code in every place where ambiguity may occur.

According to section 12.8 of [Stroustrup 94], the ANSI Committee considered using renaming, but this proposal was blocked by one of the Committee members, he insisted that other members of the Committee take two weeks to think about the issue. The example given in section 12.8 shows how to achieve the same effect without displaying renaming. The question is, if it takes two weeks for the experts to consider how to implement it, how much space does it leave us?

The domain parsing operator is not just used to eliminate ambiguity caused by multi-inheritance. Because well-designed languages can avoid ambiguity, domain parsing operators are ugly and complex implementation methods.

In C ++, "How to declare the parent classes in Multi-inheritance" is a complicated problem. It affects the order in which the construction function is called. When the programmer really wants to switch from the subclass to the parent class, the problem also occurs. However, we can also call this a bad programming style.

Another difference between C ++ and Eiffel is that they can directly duplicate inheritance, which allows:
Class B inherit A, A end
Class B: public A, public {};
But it is not recognized by C ++.