In addition to the mode, sunway and I talked about C ++ last Sunday. On Tuesday, we saw Linus Torvalds quarreling with people about C ++, this has led to a big discussion in the C ++ circle in China-mengyan edition, Yunfeng edition, and Liu weipeng edition. Let me talk about it too, but the level must be much worse than the professional C ++ experts.
I know that cloud wind has recently returned from C ++ to C, and I have discussed with him about whether C needs to provide GC. The main points sunway discussed with me on that day were similar to those of Yun Feng and Torvalds. In fact, they did not say that C ++ is absolutely useless, but C ++ is by no means omnipotent-I think this is the biggest mistake made by C ++'s hardcore supporters in this quarrel.
As the core developer of git, Torvalds's choice of C certainly has his own reasons. If kakurin is uncomfortable, you can use C ++ to write a similar stuff to compete.
In fact, I don't quite agree with the so-called "mental baggage" in C ++. It's important to see whether it's a burden. As Meng Yan said, "using C design and C ++ coding" is a way to get rid of the "mental burden. However, it must be acknowledged that the vast majority of people will still be affected by this so-called "mental burden. When you use STL, boost, or even Loki in your program, it is inevitable that you will inevitably fall deeper and deeper, and the abstraction level is getting higher and higher. Finally, it is inevitable that you will go through over-Design and over-abstraction, deviated from the initial goal. However, C does not provide these possibilities, so c programmers can only directly go to the goal and leave all the abstractions behind.
I think C ++ and C are just like different schools in martial arts. C ++ belongs to the kind of tricks that are very gorgeous, playing well and has a lot of lethal power. c belongs to the kind of tricks that are simple and simple, but has developed some skill, it is more effective sometimes. It's like beating the dog to hold the law and lowering the dragon's hand. For high people with deep internal forces, they usually prefer the latter because it is simpler and more direct, with a fatal blow.
Duyanning's reply to Meng Yan is representative. On the surface, it is quite right. If you do not understand the implementation of STD: string, it is true that the problem is that STD: string is not good, but the problem is that for a team, in fact, it is impossible for a leader to provide members with a clear picture of where the STD: string can be used in the project, but every Member can study STD :: the implementation behind string is also unnecessary-instead, it is better to use C directly and clearly understand it.
Later sunway and I talked about this problem on MSN. STL, boost, and Loki are good, but they are not always easy to use. In his project applications, there are performance problems with STL, so they are a set of templates implemented by themselves. Because targeted implementation can minimize many general problems, and this targeted implementation is also very helpful for performance optimization (I remember that Ace is also due to performance issues, A set of template libraries ). Since STL may be discarded, other features of C ++ may also be discarded in some cases. In that case, using C is a better choice.
As le Pang said in the crowd of friends, when a group of people get together, the level of the group is only lower than that of each individual-because only to such a low level, they can reach consensus. This is not the same as the working principle of the bucket. The water volume of the bucket is determined by the shortest wooden board, and the result of the human population is lower than that of the lowest one.
Taking C ++ as an example, I had a simple discussion with Ling Hu. I think the main problem with the use of C ++'s advanced features in the team is that C ++ is very powerful, but most people do not have the ability to fully understand and use it (Ling Hu pointed out: not most people, I think most people, including many c ++ experts ). If everyone in a team is familiar with only one part of the team and is not the same, it is difficult for the team to operate normally. Unless we keep everyone at a low level and use only the parts that everyone is familiar with, then there will be no more parts than C, sometimes C is useful.
In fact, on the feature issue of C ++, sunway has a similar consensus with me and Ling Hu. At present, C ++ does not have too few feature problems, but has too many feature problems. I disagree with those that will be added, such as lambda. If I have such requirements, I will use a more appropriate language, such as Python.
As Ling Hu's comment on C ++'s positioning (to be noted ):
C ++ seems omnipotent-in terms of low level, it can be as low as C; in terms of high level, it can eliminate pointers completely at the application layer by means of various libraries and other means, it looks like Java. But the problem is that C ++ is not as good as C at the low-level end (because C is simple and direct, the compilation efficiency is very high, in addition, the target code is much more clean-it only means that the target code is not clean enough when compiled in C ++ mode), and Java (lack of GC and other high-level features) at the higher end ). Therefore, the current positioning of C ++ is embarrassing.
Sunway's opinion is as simple as C:
...... I hope C ++ can discard those flashy things and get on the right track ...... It is better to support only one type ......
I basically agree with them, so I do not think that C ++ should continue to add feature, and do not think that many c ++ of feature will certainly be better than simple C.
Supplement: Of course C is not omnipotent, but in some cases, C is indeed a better choice than C ++. In short, my point is to choose a language based on the actual situation, instead of trying to solve all the problems in one language.
Add: the centralized reply is here <= stamp.