你該怎麼學習C++——思想層面

Javascript是世界上最受誤解的語言，其實C++未嘗不是。坊間流傳的錯誤的C++學習方法一抓就是一大把。我本身在學習C++的過程當中也走了許多彎路，浪費了很多時間。

爲何會存在這麼多錯誤認識？緣由主要有三個，一是C++語言的細節太多。二是一些著名的C++書籍總在（無論有意仍是無心）暗示語言細節的重要性和有趣。三是現代C++庫的開發哲學必須用到一些犄角旮旯的語言細節（但注意，是庫設計，不是平常編程）。這些共同塑造了C++社羣的總體心態和哲學。

C++中衆多的細節雖然在庫設計者手裏面有其用武之地，但普通程序員則根本無需過多關注，尤爲是沒有實際動機的關注。通常性的編碼實踐準則，以及基本的編程能力和基本功，乃至基本的程序設計理論以及算法設計。纔是真正須要花時間掌握的東西。

學習最佳編碼實踐比學習C++更重要。看優秀的代碼也比埋頭用差勁的編碼方式寫垃圾代碼要有效。直接、清晰、明瞭、KISS地表達意圖比玩編碼花招要重要…

至於這種摳語言細節的哲學爲什麼能在社羣裏面呈野火燎原之勢，就是一個心理學的問題了。想像人們在論壇上討論問題時，一個對語言把握很細緻的人確定可以獲得更多的佩服，而因爲論壇上的問題大可能是小問題，因此解決實際問題的真正能力並不能獲得顯現，也就是說，知識型的人可以獲得更多佩服，後者便成爲動力和仿效的砝碼。然而真正的編程能力是與語言細節不要緊的，熟練運用一門語言可以幫你最佳表達你的意圖，但熟練運用一門語言毫不意味着要把它的邊邊角角全都記住。懂得一些常識，有了編程的基本直覺，遇到一些細節錯誤的時候再去查書，是最節省時間的辦法。

C++的書，Bjarne的聖經《The C++ Programming Language》是高屋建瓴的。《大規模C++程序設計》是挺務實的。《Accelerated C++》是最佳入門的。《C++ Templates》是僅做參考的。《C++ Template Metaprogramming》是精力過剩者能夠玩一玩的，普通程序員碰都別碰的。《ISO.IEC C++ Standard 14882》不是拿來讀的。。。

I suspect that people think too little about what they want to build, too little about what would make it correct, and too much about "efficiency" and following fashions of programming style. The key questions are always: "what do I want to do?" and "how do I know that I have done if?". Strategies for testing enters into my concerns from well before I write the firat line of code, and that despite my view that you have to write code very early - rather than wait until a design is complete.

Obviously, C++ is very complex. Obviously, people get lost. However, most peple get lost when they get diverted into becoming language lawyers rather than getting lost when they have a clear idea of what they want to express and simply look at C++ language features to see how to express it. Once you know data absreaction, class hierarchies (object-oriented programming), and parameterization with types (generic programming) in a fairly general way, the C++ language features fall in place.

Well, I don't think I made such a trade-off. I want elegant and efficient code. Sometimes I get it. These dichotomies (between efficiency versus correctness, efficiency versus programmer time, efficiency versus high-level, et cetera.) are bogus.

I think the real problem is that "we" (that is, we software developers) are in a permanent state of emergency, grasping at straws to get our work done. We perform many minor miracles through trial and error, excessive use of brute force, and lots and lots of testing, but--so often--it's not enough.

Software developers have become adept at the difficult art of building reasonably reliable systems out of unreliable parts. The snag is that often we do not know exactly how we did it: a system just "sort of evolved" into something minimally acceptable. Personally, I prefer to know when a system will work, and why it will.

There are more useful systems developed in languages deemed awful than in languages praised for being beautiful--many more. The purpose of a programming language is to help build good systems, where "good" can be defined in many ways. My brief definition is, correct, maintainable, and adequately fast. Aesthetics matter, but first and foremost a language must be useful; it must allow real-world programmers to express real-world ideas succinctly and affordably.

I'm sure that for every programmer that dislikes C++, there is one who likes it. However, a friend of mine went to a conference where the keynote speaker asked the audience to indicate by show of hands, one, how many people disliked C++, and two, how many people had written a C++ program. There were twice as many people in the first group than the second. Expressing dislike of something you don't know is usually known as prejudice. Also, complainers are always louder and more certain than proponents--reasonable people acknowledge flaws. I think I know more about the problems with C++ than just about anyone, but I also know how to avoid them and how to use C++'s strengths.

In any case, I don't think it is true that the programming languages are so difficult to learn. For example, every first-year university biology textbook contains more details and deeper theory than even an expert-level programming-language book. Most applications involve standards, operating systems, libraries, and tools that far exceed modern programming languages in complexity. What is difficult is the appreciation of the underlying techniques and their application to real-world problems. Obviously, most current languages have many parts that are unnecessarily complex, but the degree of those complexities compared to some ideal minimum is often exaggerated.

We need relatively complex language to deal with absolutely complex problems. I note that English is arguably the largest and most complex language in the world (measured in number of words and idioms), but also one of the most successful.

C++ provides a nice, extended case study in the evolutionary approach. C compatibility has been far harder to maintain than I or anyone else expected. Part of the reason is that C has kept evolving, partially guided by people who insist that C++ compatibility is neither necessary nor good for C. Another reason-- probably even more important--is that organizations prefer interfaces that are in the C/C++ subset so that they can support both languages with a single effort. This leads to a constant pressure on users not to use the most powerful C++ features and to myths about why they should be used "carefully," "infrequently," or "by experts only." That, combined with backwards-looking teaching of C++, has led to many failures to reap the potential benefits of C++ as a high-level language with powerful abstraction mechanisms.

The question is how deeply integrated into the application those system dependencies are. I prefer the application to be designed conceptually in isolation from the underlying system, with an explicitly defined interface to "the outer world," and then integrated through a thin layer of interface code.

Had I had a chance to name the style of programming I like best, it would have been "class-oriented programming", but then I'm not particularly good at finding snappy names. The school of thought that I belong to - rooted in Simula and related design philosophies - emphasizes the role of compile-time checking and flexible (static) type systems. Reasoning about the behavior of a program has to be rooted in the (static) structure of the source code. The focus should be on guarantees, invariant, etc. which are closely tied to that static structure. This is the only way I know to effectively deal with correctness. Testing is essential but cannot be systematic and complete without a good internal program structure - simple-minded blackbox testing of any significant system is infeasible because of the exponential explosion of states.

So, I recommend people to think in terms of class invariants, exception handling guarantees, highly structured resource management, etc. I should add that I intensely dislike debugging (as ah hoc and unsystematic) and strongly prefer reasoning about source code and systematic testing.

Pros: flexibility, generality, performance, portability, good tool support, available on more platforms than any competitor except C, access to hardware and system resources, good availability of programmers and designers. Cons: complexity, sub-optimal use caused by poor teaching and myths.

 

參考網頁：https://blog.csdn.net/pongba/article/details/1611593

　　　　　https://blog.csdn.net/doulmi/article/details/6937800