I wrote a sequel to "C ++ is not omnipotent". Ling Hu reminded me:
C ++, as a language, has no problems with any features and does not have any "extra features. From this perspective, all the efforts of the C ++ Standards Committee are meaningful. Because they are improving C ++Language itself.
However, as a project developer, the development language is notUnique. There is no need to restrict the language inUse onlyC ++. In this context, the combination of other languages may be better than a single use of C ++. Especially for C ++, the compiler's implementation of the standard may not be complete and correct.ComplexIt is risky to use a language that is too "advanced. In fact, many companies make more or less reductions through code standards when actually using C ++ to reduce the use of "C ++ advanced features.
When talking about this issue, it is better to put theory and practice into practice. Put together the debate on language characteristics, language development, and the debate on the application of language in the project, it is easy to bypass yourself.
I realized that there was something wrong with it, so I changed it to the current article, mainly as a reply to some of the previous comments.
As fastzhao said, language problems are "just a matter of faith" in most cases ". This is only because kakurin has to impose its beliefs on Torvalds. In the kakurin's opinion, C ++ is omnipotent. Torvalds does not use C ++, but I don't think so, so I am involved.
It is ridiculous to sacrifice Bjarne or the Standards Committee, because, as Ling Hu said, the application of language itself and language is two different things. Masters such as Bjarne are considering the problems of language itself, we are considering application issues.
The location of a person determines the TA's perspective. It is just an empty talk to talk about the problem. Therefore, I have repeatedly stressed in the previous article that C ++ is not always the most suitable for Torvalds's git and cloud wind or sunway projects. They are all experienced development experts and take into account more comprehensively than kakurin in terms of language application.
It is undeniable that many of C ++'s feature is a good thing. A single template makes the number of other language users drool. But it doesn't mean that C ++ has all the feature of C (old version) and provides more possibilities, so c ++ is certainly better. For example, in C, a phrase "A = B + C;" can be understood by every C programmer, and there is usually no misunderstanding, for C experts, you can even see at a glance what the target code will look like. But in C ++? Who knows whether the plus sign has been overloaded with operators.
As duyanning and laibach0304 said, it is correct to understand it when it is used. But this is only in the position of a coder, and as a leader, it is impossible for every member of the team to do it. Dick_song said that leader should know the proper use of Members when assigning personnel, but as a company, especially a software company, it is very important to reduce the cost of human resources, therefore, the leader has no right to decide what level it can use.
Duyanning said he couldn't think of anything suitable for C rather than C ++. If you only consider the technical aspects of personal use, it is indeed difficult for me to think of anything that suits C rather than C ++. But what if it is at the team application level of a real project? I can't think of it, but it's because there are not enough situations.
Dogdotnet is right. c ++ can only be controlled by a few excellent programmers, but what a software company wants is production efficiency. It cannot wait until all programmers in the company grow into excellent programmers, the C ++ code written before they have grown up is not only inefficient, but also quality.
As for the mainstream languages I have used, C ++ is undoubtedly the closest and omnipotent. But "yes" does not mean "good ". For example, tuple and boost also have tuple. However, compared with Python's simple and direct tuple, boost's tuple is obviously ugly.
Liu weipeng spoke well in "Why c ++". As long as he uses C ++ with caution, it does provide us with more possibilities. You can exercise caution and do as much as possible, but you can only exercise caution for the leader in the team, however, to what extent they can achieve is unknown-of course there are many management methods that can be controlled to a certain extent, such as code review, but for companies, this will increase the development cost.
By the way, it is the cost!
For a single programmer, all costs are their own, so the benefits of C ++ are real benefits. However, for a team, there will be a lot of extra costs to consider, such as the costs required for the training team members to reach a certain level, such as the cost of code review, for example, the modification cost caused by a Member's misuse of a feature in C ++ ...... Is the benefit of C ++'s advanced features sufficient to compensate for these costs?
Considering all the costs, as a leader, you may have to restrict the use of C ++'s advanced features in the team, or even use C in some extreme situations. This is not surprising.
The language itself is mainly a technical issue, while the application of the language needs to face more technical issues.