學(xué)習(xí)C++你是否會有以下幾點(diǎn)誤解？

如果你中槍了，說明這篇文章適合你看。對某些人，某些任務(wù)，在某些時間，其中一些誤解曾經(jīng)只是正確的。然而，在如今的C++，應(yīng)用廣泛使用的最先進(jìn)的ISO C++ 2011編譯器和工具，它們只是誤解。

下面來一一解釋

學(xué)習(xí)C++基礎(chǔ)編程比學(xué)習(xí)C要容易地多。

C幾乎是C++的一個子集，但是它不是最先要學(xué)習(xí)的最好的子集，因?yàn)镃缺少計數(shù)支持，類型安全，和易用的標(biāo)準(zhǔn)庫，而C++為簡單任務(wù)提供了這些。

C++支持OOP和其他編程風(fēng)格，但它并不局限于狹隘的“面向?qū)ο蟆薄ＫC合地支持了包括面向?qū)ο蠛头盒途幊碳夹g(shù)。通常，一個問題的最優(yōu)解決方案，包含不止一種風(fēng)格（范例）。“最優(yōu)”，我指的是最短、最易于理解、最有效率和最易于維護(hù)等。

“C++是一門面向?qū)ο蟮恼Z言”使人們認(rèn)為C++不是必要的（當(dāng)與C做比較時），除非你需要一個巨大的類繼承層次以及很多須函數(shù)（運(yùn)行時多態(tài)）——對很多人和很多問題，這樣應(yīng)用并不合適。相信這個誤區(qū)導(dǎo)致C++因?yàn)椴皇羌兠嫦驅(qū)ο蠖獾阶l責(zé)；畢竟，如果你把“好”和“面向?qū)ο蟆钡韧饋?，那么C++明顯包含了很多不是面向?qū)ο蟮臇|西，一定會被認(rèn)為是“不好”。不管是哪種情形，這個誤解為不學(xué)習(xí)C++提供了一個很好的借口

在回收不再使用的內(nèi)存上，垃圾回收做的很好，但是并不完美。它并非靈丹妙藥。因?yàn)閮?nèi)存可以被間接地引用，并且很多資源并不是普通內(nèi)存。

許多人相信高效率的代碼必須是底層代碼。一些人甚至認(rèn)為底層代碼天生就是高效的（“如果代碼很丑陋，那它一定很高效！一定有人花費(fèi)了大量時間和精力來優(yōu)化它！”）。當(dāng)然，你僅僅使用底層代碼是可以寫出高效代碼的，并且有時在直接處理機(jī)器資源時必須使用底層代碼。

然而，你一定要衡量一下工作是否有價值：現(xiàn)代C++編譯器非常高效，而現(xiàn)代機(jī)器架構(gòu)非常復(fù)雜。如果必須使用底層代碼，一定要通過接口封裝起來，以便于使用。通常，通過高層接口封裝底層代碼，會帶來更好的優(yōu)化（如，避免“濫用”底層代碼）。在關(guān)注效率的場合，首先嘗試用高層抽象來呈現(xiàn)需要的解決方案，而不要不加考慮地使用比特位和指針。

C++是一個巨型的語言。它定義的大小和C#與Java差不多。但是這并不意味著你必須知道每一個細(xì)節(jié)，或者在每一個程序中都用到所有特性。

接下來再說一個C++非常經(jīng)典的易犯錯的案例

不能將 memcpy()、strcmp() 以及其他一些標(biāo)準(zhǔn)函數(shù)的返回值，和 1、-1 這些具體的數(shù)字做比較，因?yàn)檫@些函數(shù)的返回值只保證大于 0 或者小于 0（譯注：而并不保證大于0就等于1，小于0就等于-1）。

上面那段錯誤的代碼可能在很長時間內(nèi)都能正常工作。不過那僅僅是因?yàn)檫\(yùn)氣好而已，沒什么其他原因。某一天你寫的函數(shù)很可能突然間就崩潰了 —— 比如，你換了一個編譯器編譯源代碼，或者通過其他方式優(yōu)化了 memcpy() 函數(shù)。然后你的代碼就不能正常工作了。

不要依賴函數(shù)本身的行為。如果文檔上說一個函數(shù)能返回一個不等于 0 的值，那它就是這么實(shí)現(xiàn)的。也就是說這個函數(shù)可能返回 -10、2 或者 1024。你可能經(jīng)常看到函數(shù)的返回值就是 -1、0 或者 1，但是這并不能保證它每次都會這么做。

這個錯誤是通過 PSV-Studio 靜態(tài)分析工具掃描分析得到的。錯誤文本如下：V698 表達(dá)式 “memcmp(…) == -1“ 是不正確的。這個函數(shù)可能的返回值不一定只有“-1”，而可能是任何負(fù)數(shù)。請考慮到使用 “memcmp(…) < 0="">

• 你的計算機(jī)專業(yè)還有就業(yè)前景嗎？
  

• 大學(xué)老師的掙扎：嚴(yán)格還是放水？

• 傳智IT教材榮獲中國大學(xué)出版社優(yōu)秀暢銷書獎

戳原文，參與有獎教材挑錯！