Is C ++ just a language for objects?

The C ++ language is actually a collection of different languages. You can regard it as a language or a language, and you need to develop C ++ programs, the complexity will increase significantly, which is one of the main reasons why C ++ is difficult to control in practice.

Mixed Use of different styles is like mixing multiple languages in a single source file, which inevitably exposes complexity and inconsistency. Of course, the unique charm of C ++ lies in the power of mixed-style programming. This is a double-edged sword. Although it has the potential power, it is usually an important cause of Project chaos.

In my opinion, the following principles can be used for actual development to avoid risks to a certain extent:

1). Use only one programming style at any single point in time.

2). Use a style to organize the development of the overall module.

3 ). in a typical scenario that is particularly suitable for another style, you can use a sub-module to package the scenario and then use the style in the sub-module, but remember to follow requirement 1, avoid mixed style. In addition, the module must be packaged by means of encapsulation to meet the requirements of the Subject style. For example, if the main style is better C and object-oriented is used in a sub-module, the sub-module should look like a general C process as a whole.

4) In some cases, the mixed style does have great advantages. However, this situation is rare. Generally, the successful practices have been summarized as patterns, so in actual engineering practice, we can forcibly stipulate that, the hybrid style can be used with caution only when it meets a patterns. It is strictly prohibited to create new hybrid usage without authorization.

Now let's discuss how to divide the C ++ style. Stroustrup classifies the C ++ style from the perspective of language developers. If we classify the following principles, I think different results will be obtained:

1) Each style must constitute a complete sub-language with completeness. You can use this sub-language to develop any software system independently, with proven experience.

2) Each style must be relatively simple with consistent, simple, recognized, and verified principles.

3) each seed language must be able to find other corresponding languages in the real world.

Based on the above principles, I divide the C ++ language into three and a half languages:

1) Better C only adds a subset of class C with simple features such as function overload, reference type, and default parameter. Corresponds to the ansi c language.

2) adt c ++, that is, C with Class. The whole program is composed of concrete class objects with no inheritance and polymorphism. Corresponding to Ada 83 language.

3) idl c ++ is called Interface-Oriented. A typical example is the COM component model.

3.5) gp c ++, using the template technology to form a library and component implementation language. This is not a complete sub-language. On the one hand, we can regard it as an extension of adt c ++, and on the other hand, it must be attached to other styles to play a role.

Obviously, I have left the most important style here, that is, what we usually call the "Traditional Object-Oriented" style, which is presented by Smalltalk, Java, and other languages. A style demonstrated after years of practice by class libraries such as MFC: It abstracts and organizes various data types by a huge inheritance tree and achieves code reuse by inheritance and combination. Why is this style not mentioned by me?

Because I think this style is actually a mixed style! It can be considered as an attempt to integrate the above 2nd, 3, and 3.5 styles. In the above three principles, it seriously violates the second. Due to the static nature of C ++, C ++ lacks natural class libraries and garbage collection mechanisms, it is very difficult to program Smalltalk in C ++, to overcome these difficulties, C ++ has developed a unique "object-oriented" programming style different from Smalltalk and Java.

After nearly 15 years of practice, we should say that there are successes and failures. Although a large number of books have been published, there is no simple, consistent, and reproducible style guide. In a sense, the increasing popularity of so many C ++ object-oriented programming guidance books over the past decade just shows the difficulty and difficulty of this style.

Personally, I am no longer guided by this style. I will not try my best to construct an inheritance tree and think about which functions should be virtual functions. You can think that "inheritance to reuse code" is a sign of this style.

Please note that adt c ++ allows combinations. do everything possible to avoid inheritance. The typical representative of idl c ++ is COM, which does not support this inheritance. It only supports interface reuse. Of course, this does not mean denying the development achievements of C ++ in Object-Oriented aspects over the past decade. However, if you plan a complete project from the beginning, I think it is unwise to choose this combination style. However, this style has two typical application scenarios:

1) there is a complete framework support. For example, MFC. Although this style has many technical difficulties, the framework like MFC has helped you overcome some of them and created a relatively comfortable environment like Smalltalk. This style can be used at this time. However, we usually need to realize that such frameworks introduce some new problems while overcoming many technical difficulties. Sometimes they are more difficult to deal with. Therefore, we should be wise and be fully prepared.

2) conforms to the classic mode. If a typical "Object-Oriented" scenario has mature, excellent, ready-made, and documented design solutions, you can choose and use it with caution. I am mainly referring to GoF and some other design templates.

Here, the so-called "Classic Mode" is definitely not too many, but it appears in a large number and repeatedly in the design, and often appears in combination. In this case, it is very suitable to use a verified design solution. I personally have some practices here and I think I should pay attention to several issues. First, be cautious. I have encountered a lot of situations and it seems very suitable to use a certain mode to solve them. However, only when I use it can I find that this is not the case.

Applying a wrong pattern in an unsuitable place will make things messy. Second, it is best to localize and package the design scheme so that you can't see what pattern you are using from the outside. Third, pay attention to memory issues. The biggest obstacle to using the OO style is the memory problem.

1. Introduction to C ++
2. Summary Notes on learning and exploring C ++ library functions
3. Basic Conception and method of C ++ Class Library Design
4. Does C ++ really have market value?
5. Basic Conception and method of C ++ Class Library Design