It's not prejudice, it's "barge ' C" is dead.

>> bias is always an individual, not a group. The author added the following sentence, no doubt that the biased is not a C + + programmer, but it is himself.

Wrong, the truth is on the minority side, when a change will occur, biased often is the public is the traditional force.

The >> is even more absurd. Have you ever seen a good C + + code? The C + + standard library (STL) is so elegant. Moreover, there are so many classic C/s Open source works, as well as inadvertently leaked Windows NT core source, which is not a masterpiece? I feel sorry for the author shallow.

STL code is not elegant, the lack of functional programming mechanism support for the implementation of C + + algorithm very far-fetched, for example, I want to find (V.begin (), v.end (), compare); V is a custom structure, I have to write a comparison function outside of the function, if you want to take some context to write a functor class, very ugly, practical greatly discounted. In the case of FP, it is very natural to write an anonymous function. The concepts of containers, algorithms, etc. in the STL are already natively supported in FP, and are much more elegant. As for the NT code this I have not seen bad, but it is said that the code has a lot of the original programmer left the complaint bug and design mistakes.

>> memory Management is the most classic topic in the program design. The GC is undoubtedly a great change in memory management, but I just think of it as a solution to memory management and not the only solution. A more elegant solution than GC is not necessarily. I prefer to choose the right memory management scheme in a particular situation, rather than having no choice, which is the great thing about C + +. All of those GC languages (such as Java, C #, etc.) impose this solution on programmers, which in some ways ease the burden on programmers, but also constrain the programmer's initiative. "Allocate memory and release within the C language is very slow"? Do not know where the author obtained the conclusion.

To be honest, I don't like GC, and C with no GC can work fine, but no GC is not working correctly for the FP language, so I still have to accept the GC thing. Of course what I like more is the way to combine the two.

There is really not much multithead support for the >> C + + language itself, which is expected to change after c++0x. However, keep in mind that C + + is always inclined to use a mature library to solve the problem.

This will be the biggest reason for the decline of C + +, which cannot adapt to the future development of the multi-core era. The library cannot really solve the problem, what we need is further development at the language level.

>> pointer is too flexible embodiment of C/s + +. Code that uses pointers can be very ugly, but it can be elegant. --There is no difference in what language to use at this point. I believe that you can write elegant Java code, you can also write the same elegant C + + code. The converse is not necessarily (because some C + + paradigms are not supported by Java). It is confusing, but not necessarily inferior, that there are too many choices in C + + language. My advice to the C + + programmer is to learn more about and use the C + + standard library, rather than the details related to overly entangled pointers.

>> algorithm optimization is the key to program design. But in general, programmers in all languages (including C + +) are studying the optimization of critical paths. Is the study *p++ faster than P[i]? I believe this is what the implementation of the standard library should consider. The difference is that a C + + programmer can consider these details as well as the authors of the standard library, while programmers in other languages are deprived of that right.

When it comes to optimization, the topic is much more. I have inserted 100 million integers (read from more than 10,000 text files) into C # 's dictionary and found that the program has been running for a whole afternoon and still not finished. And I switched to C + + std::map,20 minutes to get it done. Try to sort the 500,000 custom structure data, and I believe you, like me, will love the efficiency and elegance of C + +.

Many years ago programmers also assembled in C programs to achieve code-level optimizations, but no one has done so now because CPUs are getting more complex, and most compilers do better than manual ones. Today's java/. NET JIT engine has also been able to achieve a very high level of optimization, in the performance of C code advantage has become increasingly less obvious. For the future, code-level optimization is no longer the focus, which language can adapt to the development of multi-core, who will become the King of performance.

The language of >> freshmen must be improved on the basis of absorbing the old language. To see the vitality of a language is not to look at the deficiencies in some parts of it. Things develop and tend to be perfected. Believe that the c++0x out, C + + language will gain new vitality. Just look at Java, C # and other new generation of languages, which have so many C + + brand, it is proved that the impact of C/s + + is enormous. It is shallow to say that a language is dead.

To say a language died, not to say completely disappear, but to exit the mainstream development language ranks, gradually marginalized, these years to preach C + + people have been less and more, in many development areas of C + + 's status has been replaced by Java,. NET, scripting language, etc. C++0x out is not important, but the emergence of C++/CLI brought to C + + some new ideas, but although I appreciate c++/cli, but it will not become the mainstream. When Multi-Core arrives, the programming language is not ready, the future we will face is not 2 nuclear 4 nuclear, but the hundred nuclear, such a scale, not only in the field of algorithm to continue to develop, programming language to come to a major change to adapt to this development, as to the direction of where the FP system language may bring you some inspiration.