The return of C

The return of C

Weekend trip to another city to the company to solve a project problem. On my way to the airport, I used Google reader on my cell phone to pass the time. At first glance saw Meng Yan a big new article: The father of Linux is not rough. The theme is the battle between C and C + + language. Go to Liu Jiang's blog to read the Linux father shelled C + +: Bad Programmer's garbage language is very enjoyable. Immediately send the link SMS to a few friends.

The Battle of language is always the subject of gunpowder. In particular, C and C + + target market has a high overlap, C + + programmers tend to C + + it has religious piety. I think, today I in my blog to continue this war, will be replaced by more infamy. But this time Linus a few words really said my heart went, do not shout out will suppress bad:D

First of all, to the unfamiliar with my friends to do a technical background of self-introduction:

I am not a Linux fans, although I do not have a good impression of Windows today, but most of my work is on Windows on the application of software development, is familiar with Windows. Now I'm using a non-Windows system, but it's a FreeBSD machine, not Linux.

I think I'm pretty familiar with C + +, and I've read most of the books on the market that I can buy about C + +, like D&e of C + +. Write in C + + at least hundreds of thousands of lines of code, read most of the STL source, and ace/boost a small part.

Once I was a loyal fan of C + +, if anyone said that C + + is not, either would choose to debate with him to the end, or will be dismissive of this person.

And I think it's very important: I first fell in love with C + + 15 years ago (1992), and then slowly cooled back to the embrace of C. And by the year 2000, I fell in love with C + + again. That is, from the love of C + + to deny it, in my personal experience, there have been two times. Not to rule out the possibility of a third time in the future, but this is enough to show that the negation of C + + is a rational judgment, not an impulse.

Write these, not to want to imposes. I know, want to scold my C + + programmer, more hate someone imposes grumble about C + + is not. And on the qualification, I at most and the Linus greatly a fraction, since there are old people in front of the backing, the following words of the emboldened can be sufficient:)

C is a subset of C + + (from the beginning of C99), with C can write out the code, C + + can be written out, and then can be done better.

This is the Novice's self-righteous assault weapon. Linus used a very good reason to fight back: "You can of course write bad code in any language." However, some languages, especially those with some mental baggage, are very bad in themselves. ”

Yes, that's what I want to say. C + + is a "language with some mental baggage". This has a huge impact on software design, which is hard to understand without years of software development practice.

From this point on, it is meaningless to compare the problems of ASM and C with the comparison of C and C + +.

The next question to find is, C + + more than c out of those things, will it really bring mental baggage? This question is not a good answer. It is difficult to convince myself of these angles from the complexity of the C + + language features, let alone convince the C + + programmers who are smarter and more diligent than me. I think I have a good grasp of the advanced features of the so-called C + +, and use it in many practical projects. They are quite interesting and, in a way, very effective. The code can achieve a fairly high level of execution efficiency and can shorten the encoding time (fewer keystrokes) and accomplish them with a great sense of accomplishment.

Well, let me quote Linus's words in my heart. "String/memory management doesn't really matter. This is not an important part, and it is not complicated. The only really important part is the design. ”

Design! This is the most serious of all.

If I were to say, what have I learned in this last 10 years of programmer life? I think I can design better code than I used to. Can more accurately grasp the bad taste of the design. The Master of programming language, familiar with the operating system, knowledge of work-related and so on. Those are the things that happen spontaneously, those are the accumulation of knowledge, not the improvement of ability.

"Abstract", "Object Oriented", "design pattern", are these important? Important. is very important for software development. But important is not necessary, obsession with "abstraction" will make you more and more distant from the goal. When we extract the generality of things over and over again and build up the abstraction layer, we may discard the truth. C + + inherits the design philosophy of "trusting programmers" in C, and is dedicated to allowing programmers to create abstraction layers without additional consumption. His solution is to provide as many language tools and design choices as possible, and any one allows you to do nothing without additional performance damage.

This is a beautiful vision: C + + programmers expect to build a powerful reusable abstraction layer in the face of all the specific applications in the world. At the same time the CPU execution sequence passes through this thick layer of abstraction, which can be passed at the speed of light (with no extra execution efficiency through the abstraction layer). For this reason: the C + + community created the STL and created Boost. Their common key words are: efficiency, reuse.

Up again? Another problem arises: "--inefficient abstract programming model, you may notice in two years that some abstractions are not good, but all the code already relies on the ' pretty ' object model around it, and cannot be corrected without rewriting the application. "This paragraph is still the Linus language, I keep quoting, because I understand this, but can not express more clearly."

Programmers using C + + constantly emphasize reusability, but they constantly need to rewrite the code. If a piece of code can not be rewritten, it is mostly because of a compromise on rewriting the amount of work. Yes, we can actually write better, prettier, and more efficient code in C + + 's various features. Two years ago the framework is not so perfect, not the C + + language of the fault, two years ago, my ability is limited. But because the design framework needs to be rewritten, it means that we have to follow the changes to the completed function module, or add the bridging layer.

Indeed, both STL and Boost are done by the world's top programmers. The code quality is very high (of course, I have reservations about part of Boost). I don't say anything about compiler compatibility and portability or the speed of compiling, although these are real problems, but not enough to be a reason to oppose the C + + base Class library.

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

However, the STL is too large, and Boost is even more. I am not complaining about the difficulty of reading and learning their source code and the time and effort required. On the contrary, I am filled with joy and gratitude in the course of learning them. Master seniors have taught me a lot through these high-quality code. What I'm worrying about is that this huge code, its design can't always be right. Two years later, they must have been in the right design for another two years. But I'm almost sure that in the longer term, it's definitely not the best choice in some areas of design. Will we choose to change that day? I think the C + + community will be forced to choose compromise. However, the C + + Programmer's heart is full of pain.

C the choice on this issue is not the same. On the issue of efficiency, the most worrying thing in C programs is the consumption of function calls. The most popular case for C + + programmers is that Std::sort completely defeated the Qsort in the C library. C-language failures are being consumed by redundant function calls.

However, from the outset, C has chosen to admit the consumption of function calls, which is almost unique. After paying this price, the problem of inefficiency caused by design errors can almost always be avoided. Both C and C + + can choose to rewrite the part of the design failure, but not the same, the C programmer can almost not consider the problem of compromise. The same is to consider the language of extreme efficiency, C language frankly face defects, is really in line with the KISS principle.

My views on this question can be Linus by quoting the passage of the word. "If you want to use a more fancy language, C + + is definitely the worst choice. If you want real advanced features, then choose to have garbage collection or good system integration, rather than lack of C's simplicity (sparseness) and lack of C's direct and no important concept of high-level binding (high-level bindings to important Concepts) of things. ”。 This is the point I've been insisting on in the last few years: the development of C + + must complement the features required for GC support.

I don't hate C + +:), I emphasize. C + + fans can scold me casually, but do not bring class hatred.

PS. I've been working on a game engine project for more than two years. This project is now the third version. The first version is implemented in C + +, but does not use any existing class libraries (including STL). In the second version, I removed all the parts that were implemented using the C + + advanced features and implemented all with the C + + basic features only. The third version rewritten this year, all changed to C code. The development of this project can reflect my personal mind-to-C + + understanding of the mental process.

The return of C