C language Regression

Text/Yunfeng

Language competition is always a topic of fire and medicine. In particular, the target markets of C and C ++ are highly integrated. C ++ programmers tend to be religious to C ++. I think today, I will continue this war on my blog, and I will surely get more names. But this time Linus said a few words in my heart. If I don't shout it out, it will be broken: D

First, let me introduce myself to my friends who are not familiar with the technology background:

I am not a Linux fans. Although I have little affection for Windows today, most of my work is still on Windows for application software development, and I am still familiar with Windows. I also use a non-Windows system, but it is a FreeBSD machine, not a Linux system.

I think I am quite familiar with C ++ and have read most of the books about C ++ available on the market, A classic like D & E of C ++ has read more than once. I have written at least 100,000 lines of code in C ++, read most of STL source code, and a small part of ACE/Boost.

I used to be a loyal fan of C ++. If anyone who says that C ++ is not, they will either choose to argue with him to the end, or they will disregard this person.

Another point I think is very important: I fell in love with C ++ for the first time 15 years ago (in 1992), and then gradually turned cold to it and moved back to the embrace of C. In 2000, I fell in love with C ++ again. That is to say, from loving C ++ to denying it, there were two times in my personal experience. It does not rule out the possibility of a third time in the future. However, it is clear that the denial of C ++ is based on a rational judgment rather than an impulse.

Writing these words is not intended to depend on old people. I know, I want to scold my C ++ programmers, and I hate people who depend on the old and sold old. In addition, on the qualifications, I have at most reached a fraction of Linus. Since there are old people standing in front of me, I can have enough confidence in the speech below :)

C is a subset of C ++ (not from C99). code that can be written in C can be written in the same way as C ++, which can be better accomplished.

This is a self-righteous attack weapon. Linus used an appropriate reason to fight back: "Of course you can write bad code in any language. However, some languages, especially those with mental burdens, are very bad ."

That's all I want to say. C ++ is a language with mental burdens ". This has a huge impact on software design, and it is hard to understand this point without years of software development practices.

From this point, it makes no sense to compare the problem of ASM and C with the comparison of C and C ++.

The main point to be found next is that after C ++ is more than C, will it really bring mental burden? This question is hard to answer. It is difficult for me to convince myself of the difficulty of understanding and misuse caused by the complexity of the C ++ language, let alone to persuade those who are smarter than me, many hard-working C ++ programmers. I think that I have a good grasp of the so-called C ++ advanced features and use them in many practical projects. They are quite interesting and very effective to some extent. Code can achieve a very high execution efficiency, and shorten the coding time (less key-hits), they also have a great sense of accomplishment.

Well, let me introduce Linus's words to my heart. "String/memory management doesn't matter at all. This is not an important part and is not complicated. The only really important part is design ."

Design! This is the top priority.

What have I learned from my programmer career over the past 10 years? I think I can design better code than before. Can more accurately grasp the bad taste of the design. Understanding of programming languages, familiarity with operating systems, and work-related knowledge. What happens naturally is the accumulation of knowledge rather than the improvement of ability.

Are "abstraction", "Object-Oriented", and "design patterns" important? Important. It is very important for software development. But it is not necessary to be important. Being obsessed with "abstraction" will keep you farther and farther away from your target. When we extract the commonalities of things and establish an abstraction layer, we may discard the truth. C ++ inherits the design philosophy of "trusted programmers" in C language, and is committed to enabling programmers to create abstraction layers without additional consumption. The solution is to provide as many language tools and design options as possible. Any one allows you to avoid extra performance loss when you do not need to use it.

This is a beautiful vision: C ++ programmers expect to build a powerful reusable abstraction layer to face all the specific applications in the world. At the same time, the CPU execution sequence can pass through this thick abstraction layer at the speed of light (through the abstraction layer without extra execution efficiency ). To this end: the C ++ community has created STL and Boost. Their common keywords are efficiency and reuse.

What about going up? Another problem arises: "-- inefficient abstract programming model. Maybe two years later, you will notice that some abstract effects are not very good, however, all code depends on the 'beautiful' object model designed around it. If you do not rewrite the application, you cannot correct it." This paragraph is still Linus, and I keep referencing it because I understand it, but cannot express it more clearly.

Programmers who use C ++ constantly emphasize reusability, but constantly need to rewrite the code. If a piece of code does not need to be rewritten, it is probably because of a compromise on the amount of rewriting work. Yes. In fact, we can use the various features of C ++ to write better, more beautiful, and more efficient code. The framework was not so perfect two years ago. It was not a C ++ language error because of my limited capabilities two years ago. But because we need to rewrite the design framework, this means that we must follow the functional modules that have been changed or add a bridge layer.

Indeed, STL and Boost are done by top programmers in the world. Code quality is very high (of course, I have some reserved opinions on Boost ). I don't talk about compiler compatibility, portability, or compilation speed. Although these are real problems, they are not enough to be the reason against the C ++ basic class library.

Make good use of C ++, of course, use STL, Boost should also be carefully examined. It is better to read the source code carefully. Qualified C ++ programmers should do this. Otherwise, as a C ++ programmer, you violate the design philosophy of the C ++ language: C ++ trusts you, and you should assume this trust, find out what the machine is doing behind every line of code you write.

However, STL is too large, and Boost is more. I am not complaining about the difficulty and time and effort required to read and learn their source code. On the contrary, I am full of fun and gratitude in learning them. Senior Experts have taught me a lot through these high-quality code. I am vaguely worried that the design of such a huge Code cannot always be correct. Two years later, their design will certainly be correct, but it will be two years later. But I am almost sure that, in the longer term, it will definitely find that it is not the best choice in some design fields. On that day, will we choose to modify it? I think the C ++ community will be forced to choose compromise. However, C ++ programmers are full of pain points.

C's choice on this issue is different. In terms of efficiency, the most worrying part of the C program is the consumption of function calls. The most interesting case for C ++ programmers is that std: sort fully defeated qsort in the C library. The failure of C language is being consumed by excessive function calls.

However, from the very beginning, C chose to acknowledge the consumption of function calls, which is almost unique. After paying this price, the efficiency reduction caused by design mistakes is almost always avoided. Both C and C ++ can choose to rewrite the failed part of the design, but the difference is that C programmers can almost ignore the compromise issue. The same is the language that considers extreme efficiency. The C language can face the defects calmly, but it truly conforms to the KISS Principle.

In my opinion on this issue, I can reference a line from Linus to end. "If you want to use a more fancy language, C ++ is definitely the worst choice. If you want real advanced features, you should choose garbage collection or good system integration, rather than the lack of sparseness) there is a lack of high-level bindings to important concepts. ". This is what I have always insisted on over the past few years: the development of C ++ must supplement the features required for GC support.

I don't hate C ++ :). Fans of C ++ can scold me at will, but do not bring class hatred.

Ps. Over the last two years, I have been working on a game engine project. This project is now the third version. The first version is implemented in C ++, but it does not use any existing class libraries (including STL ). In the second version, I removed all the components implemented using C ++ advanced features, and only implemented using C ++ basic features. The third version to be rewritten this year has all been changed to C code. The development of this project reflects my personal understanding of C/C ++.