# [6] 綜述 ## FAQs in section [6]: * [[6.1] C++ 是一種實用的語言嗎？](#%5B6.1%5D) * [[6.2] C++ 是一種完美的語言嗎？](#%5B6.2%5D) * [[6.3] 面向對象（OO）有什么用？](#%5B6.3%5D) * [[6.4] 泛型(generic)編程有什么用？](#%5B6.4%5D) * [[6.5] C++ 比 Ada 更好嗎？（或 Visual Basic, C, FORTRAN, Pascal, Smalltalk，或其它的語言？）](#%5B6.5%5D) * [[6.6] 誰在用C++?](#%5B6.6%5D) * [[6.7] 學習 OO/C++ 需要多長時間？](#%5B6.7%5D) * [[6.8] 從商業角度看 C++有哪些特征？](#%5B6.8%5D) * [[6.9] 虛函數（動態綁定）對于OO/C++來說是主要的嗎?](#%5B6.9%5D) * [[6.10] 我來自密蘇里州。你能給我一個理由，為什么虛函數（動態綁定）造成很大的不同？](#%5B6.10%5D) * [[6.11] C++ 是否向下兼容 ANSI/ISO C？](#%5B6.11%5D) * [[6.12] C++ 標準化了嗎？](#%5B6.12%5D) * [[6.13] 何處能得到 ANSI/ISO C++ 標準的拷貝？](#%5B6.13%5D) * [[6.14]我可以問哪些“面試問題”來判斷面試者真的懂了？](#%5B6.14%5D) * [[6.15]當FAQ說“這些是_邪惡_的”，是什么意思？](#%5B6.15%5D) * [[6.16]有時會用到那些“邪惡”的東西么？](#%5B6.16%5D) * [[6.17]是否知道這些東西的技術定義很重要：“好的OO”，“好的類設計”？](#%5B6.17%5D) * [[6.18]當人們抱怨說“FAQ”這個詞太誤導人了，因為它強調問題而不是答案，因此我們需要換一個不同的詞，這時我應該怎么對他們說？](#%5B6.18%5D) ## 6.1 C++ 是一種實用的語言嗎？ 是的。 C++ 是一種實用的工具。[它不完美](#%5B6.2%5D)，但是有用。 在軟件產業的世界里，C++被看作一種可靠的，成熟的，主流的工具。它得到普遍的工業支持，因而從一種[全面的商業角度](#%5B6.17%5D)來看，它是“優秀”的。 ## 6.2 C++ 是一種完美的語言嗎？ 不是。 C++的原設計目標不是作為完美的面向對象語言的典范。它被設計為一種實用的工具，來解決現實世界的問題。像所有的實用工具一樣，它有瑕疵。不過，非完美就無用的，那是純理論的框架。而不是C++的目標。 ## 6.3 面向對象（OO）有什么用? 面向對象技術是我們所知道的開發大型的，復雜的軟件應用和系統的最佳方法。 OO：應付大型的，復雜的軟件系統時，軟件工業是“失敗的”。但是這種“失敗”實際上歸因于我們的_成功_：我們的成功使得用戶想得到更多。不幸的是我們創造了市場的饑渴，而“結構化”的分析、設計和編程技術無法滿足這種饑渴。因此需要我們創造一種更好的典范。 C++支持面向對象（OO）編程。C++ 也能夠被當作傳統的編程語言使用（作為“一種更好的 C”）或使用。基本上每種方法都有其優點和缺點。也不要在使用一種方法時期望得到另外一種技術的好處。（最常見的誤解是，如果把C++“作為一種更好的C”來使用它，那么就不要期望得到面向對象所帶來的好處。) ## 6.4 泛型(generic)編程有什么用？ C++支持泛型編程。泛型編程是一種能夠最大化代碼復用而又不損失效率的一種開發軟件的方法。（這里的“效率”嚴格來說并非必須，但有了更好。） 泛型組件非常易用，并且一般會隱藏很多復雜性，當然前提是至少要設計得好。另外一個有趣的特性是它們能夠使代碼運行更快，尤其是當這些組件被更多地 使用時。這是一種很好的情形：當你用這些組件來完成一些繁雜的工作時，你的代碼會變得更少更簡單，出錯的幾率也小些，同時代碼執行起來還更快。 大多數開發者并沒有足夠的能力來開發出這些泛型組件，但卻能夠使用它們。開發這些組件的過程是復雜痛苦的。你不斷嘗試、撓頭、在凌晨3點有了靈感然 后起床，不斷地重寫代碼（不斷重寫，不斷重寫）。一句話，要不斷迭代。像諺語所說，這是在往5磅容量的口袋里塞10磅東西。不喜歡思考、不喜歡解決難題的 人就不必費這勁了。 幸運的是，泛型組件是，呃，很通用的。所以你所在的單位通常不必開發很多泛型組件。有很多已經做好的泛型組件，例如STL。[Boost](http://www.boost.org/)里面有更多的組件。還有很多其它的庫。 ## 6.5 C++ 比 Ada 更好嗎？（或 Visual Basic, C, FORTRAN, Pascal, Smalltalk, 或其他語言？） 停！這樣的問題沒有意義。在對這個問題發表不同意見之前請先閱讀下文。 99%的情況下，編程語言的選擇是[出于商業上的考慮](#%5B6.17%5D)， 而不是技術上 的考慮。真正重要的是類似以下方面的商業上的考慮：開發機器的編程環境，目標機器是否包含運行時環境，運行時和/或開發環境的許可/法律問題，是否有受過 訓練的開發者，是否有咨詢服務，和企業文化/政策。它們扮演的角色一般比編譯期性能，運行時性能，靜態還是動態類型，靜態還是綁定等更為重要。 從純粹的技術角度爭論一種語言比另一種更好的人（他們忽略了商業問題其實更重要），正是暴露了他們自己技術上的缺乏，別聽他們的。[商業問題比技術問題更重要](#%5B6.17%5D)，任何沒有意識到這一點的人注定會做出帶來糟糕后果的決策。這些人對雇主來說是危險的。 ## 6.6 誰在用 C++? 很多很多公司和政府部門，非常多。 有大量的開發者（并且因此有大量的底層有效支持，包括廠商，工具開發者，培訓等等）是[C++的特征](#%5B6.8%5D)之一 ## 6.7 學習 OO/C++ 需要多長時間？ 一些公司成功地講授標準的工業界的“短期課程”，將大學一學期的課程壓縮到了一個星期40個小時。但是不論你在何處獲得培訓，要確保課程具有動手項 目，大多數人是在接手項目之后才將概念“凝結成形”，得以學成。即使得到最好的培訓，人們也還沒能準備好。（譯注：指做實際的項目） 精通OO/C++需要6-12個月。如果身邊有專家的話，會少些。如果沒有一個“好的”通用型的C++類庫，則會多一些。成為可以指導別人的專家則需要3年。 有 些人永遠不行，除非你是可教的“儒子”并且有個人驅動力。可教的最低要求是，當你錯了的時候必須能夠承認。驅動力的最低要求是，你必須愿意投入一些額外的 時間。記住，學習一些新的東西比改變你的典范（paradigm）（即改變你思考的方法，改變你對于什么是好的認識，改變你在技術世界中的思維模式）要容易的多。 你應該做兩件事： * 找一個“指導人” * 看兩類書：一類是有關C++中什么是合法的, 另一類是有關 C++中什么是該做的。 你不應該做兩件事： * 不應該去學習 C 作為學習 OO/C++ 的臺階 * 不應該去學習 Smalltalk 作為學習 OO/C++ 的臺階 ## 6.8 從商業角度看 C++ 有哪些特征？ 從[商業角度](#%5B6.17%5D)看 OO/C++ 有這樣一些特征： * C++ 有[巨大的安裝基礎](#%5B6.6%5D)，這意味著你會有[很多廠商在工具，環境，咨詢服務等上提供支持](#%5B6.5%5D)，而且你可以在你的履歷上加上非常有價值的一條。 * C++ 讓開發者為軟件塊提供簡化的接口，以改善這些軟件塊被使用（重用）時的錯誤率。 * C++ 通過算符重載讓你利用開發者的直覺，降低重用用戶的學習曲線。 * C++ 將對軟件塊的訪問局部化，降低更改時的成本。 * C++ 減少安全性和可用性的權衡，改善使用（重用）軟件塊時的成本。 * C++ 減少安全性和速度的權衡，改善錯誤率而不喪失性能。 * C++ 給你繼承和動態綁定，以便舊的代碼調用新的代碼，使得針對市場的快速擴展／調整你的軟件成為可能。 ## 6.9 虛函數（動態綁定）對于 OO/C++來說是主要的嗎？ _是的！_ 沒有虛函數包含了許多模板以實現同樣非常好的“泛型編程（譯注：也稱通用編程，"generic programming"）”技術，但虛函數仍然是用C++進行面向對象編程的核心。 從商業角度）。 技術人員通常認為在C和非面向對象的C++之間有很大的區別，但如果沒有面向對象，這個區別通常不足以證明培訓開發者，新工具等的成本是值得的。換句話 說，如果我被某個經理征詢意見，是否從C轉向非面向對象的C++（也就是說，轉換語言而不轉換典范），那么我可能會勸阻他這樣做，除非有逼不得已的面向工 具的原因。從商業角度看，面向對象能使系統具有可擴展性和可適應性，但只有C++類的語法而沒有面向對象的話，就不會減少維護成本，而實際上會增加培訓成 本。 底線：沒有虛函數的C++不是面向對象。用類編程而沒有動態綁定則稱為“基于對象”，而不是“面向對象”。踢出虛函數和踢出OO（譯 注：即面向對象）是一回事。所剩下的就是基于對象編程了，和最初的Ada語言類似（順便說一下，新的Ada語言支持OO而不是基于對象編程了）。 注意：在[泛型編程](#%5B6.4%5D)中不需要虛函數。結合其它情況，這表明你無法通過簡單地數虛函數的數量來判斷所使用的編程范式 ## 6.10 我來自密蘇里州。你能給我一個理由，為什么虛函數（動態綁定）造成很大的不同？ 總體來說：動態綁定能通過使舊的代碼調用新的代碼來提高重用。 在 OO（譯注：即面向對象）之前，重用是通過使新的代碼調用舊的代碼來完成的。舉例來說，程序員可以寫一些代碼來調用一些重用的代碼，如 `printf()。` 在OO中，重用能夠通過使舊的代碼調用新的代碼來完成。例如，程序員可以寫一些代碼被非常非常始祖的 框架所調用。而不需要修改始祖的代碼。事實上，甚至不需要被重新編譯。即使源代碼已經遺失了25年，你只有目標文件，那個原始的目標文件將會調用新的擴展 的代碼而不會遺失什么。 這是可擴展性，這是OO。 ## 6.11 C++ 是否向下兼容 ANSI/ISO C？ 差不多。 C++盡可能地兼容C，但不完全。在實踐上，主要的區別是，C++需要原型，`f()`聲明一個不帶參數的函數（在 C 中，`f()`和`f(...)`是相同的）。 還有一些非常微小的差別，象在C++中`sizeof('x')`等于`sizeof(char)`，而在 C 中等于`sizeof(int)`。同樣，C++在同一個結構的tag名和其他名稱放在同一名字空間內，而在 C 中，需要顯式的`struct`（舉例來說，`typedef?struct?Fred?Fred;`技巧當然也可以工作，但在C++中是多余的）。 ## 6.12 C++ 標準化了嗎？ 是的。 C++標準被ISO（國際標準化組織）和一些國家標準組織，如ANSI（美國國家標準協會），BSI（英國標準協會），DIN（德國國家標準組織）所定稿和采用。ISO標準在1997年11月14日經投票一致被定稿和采用。 ANSI C++委員會被稱為“X3J16”。ISO C++標準小組被稱為“WG21”。ANSI/ISO C++標準的主要參與者幾乎包含了每個人：有來自澳大利亞，加拿大，丹麥，法國，德國，愛爾蘭，日本，荷蘭，新西蘭，瑞典，英國和美國的代表，連同大約一 百多個公司的代表和感興趣的個人。主要參與者包括AT&T，愛立信，Digital，Borland，惠普，IBM， Mentor Graphics，微軟，Silicon Graphics，Sun Microsystems和西門子。經過大約8年的工作，標準完成了。在1997年11月14日，代表們出席了在莫里森鎮的投票，標準被一致認可。 ## 6.13 何處能得到 ANSI/ISO C++ 標準的拷貝？ 準備好花錢吧——該文檔不是免費的。有很多種方法獲得這份文檔。下面列出了一些： * 訪問[ANSI](http://webstore.ansi.org/)，搜索“14882”（或對于C標準來說，搜索“9899”） * 訪問[Tech-Street](http://www.techstreet.com/)，搜索“14882”（或對于C標準來說，搜索“9899”）。 * 去任何一家書店，搜索“0470846747”或“The C++ Standard, Incorporating Technical Corrigendum No. 1.”例如，[這里](http://www.amazon.com/exec/obidos/tg/detail/-/0470846747/)，[這里](http://www.amazon.com/exec/obidos/tg/detail/-/0470846747/)，[這里](http://www.amazon.com/exec/obidos/tg/detail/-/0470846747/) * 致電給NCITS（信息技術標準國家委員會National Committee for Information Technology Standards，這是原來叫做“X3”的組織的新名字，其發音類似“insights”）。聯系人是Monica Vega，202-626-5739 或 202-626-5738。尋求FDC 14882文檔。 這里有一些相關文檔。雖然是免費的，不過不是標準本身。 * 社區草案#2是免費的，但不是正式的，也過時了，還可能有錯誤：[這里](ftp://ftp.maths.warwick.ac.uk/pub/c++/std/cd2/)和[這里](ftp://ftp.research.att.com/dist/c++std/WP/CD2/)。 * ISO委員會的新聞發布信息在[這里](http://www.research.att.com/%7Ebs/iso_release.html)。非程序員也能讀懂該發布信息。 ## 6.14我可以問哪些“面試問題”來判斷面試者真的懂了？ 這個問題主要是針對想做好面試C++應聘者的非技術性管理人員和人力資源人員。如果你是一名準備去應聘的C++程序員，并且正在翻看本FAQ希望能夠提前知道會面試什么問題，并以此來避免_真正_去學習C++，那么你應該感到羞恥：還是花點時間來提高自己的技術吧，這樣就不必靠“作弊”來生活了！ 回到非技術性管理人員和人力資源人員上：很明顯你有足夠的自個來判斷面試者是否適合你公司的文化。不過有很多假冒內行、裝腔作勢唬人的家伙，所以你 需要找一些有技術實力的人一起來判斷面試者的技術能力是否滿足要求。很多公司雇了看上去不錯但實際很廢柴的人，結果深受其害。這些人雖然知道怎么回答一些 困難的問題，但本質上是不合格的。辨別這些偽專家的唯一辦法是找人和你一起，這人要能夠提出考驗水平的技術問題。單憑自己是不行的。即使我給你一摞“迷惑 人的問題”，還是不能辨別出那些不良分子。 你的技術伙伴可能沒有（通常是沒有）足夠的資格來判斷面試者的個性或軟實力，所以在決策過程中，請不要放棄你做為最終決定者的權利。但同時也請不要認為你能夠通過問一些C++問題，就能獲得一些粗略的線索，知道應聘者是否_真的_明白他所說的東西。 已經說過了：_如果_你有足夠技術能力來閱讀這份FAQ，那么你能夠在這里找到很多好的面試問題。這份FAQ包含_很多_好問題來區分良莠。這份FAQ主要探討程序員應該做什么，而不只是編譯器允許程序員做什么。有很多C++里可以做但不應該做的事情。這份FAQ幫助人們區分這兩者。 ## 6.15當FAQ說“這些是_邪惡_的”，是什么意思？ 這表示_這些_是你在大部分時候要避免的，但_不是_在_所有_時候都要避免的。例如，最后當某些東西沒有其替代方案邪惡時。你會采用這些”邪惡“的東西。好吧，這是開玩笑的。別太當真。 這個詞的真正意圖（我聽到你說“啊哈，果然_有_隱情！”。你是對的，的確有）是讓C++新手擺脫一些舊有的思想。例如，C程序員開 始用C++時常常會過多使用指針、數組和/或#define。本FAQ將這些東西歸為“邪惡”，以便給予C++新手一個往正確方向上的有力（同時也是古怪 有趣的）推動。類似“指針很邪惡”這種搞笑說法是為了說服C++新手C++“并非除了傻傻的//注釋在其它方面就很像C了”。 現在說點正經的。我并不是說宏或數組或指針是要謀殺或綁架。呃，可能指針會干這些事（開個玩笑！）。所以不要對“邪惡”這個詞太過敏感：用這個詞只是為了為了聽上去有些夸張。所以不要試圖尋找有關哪些是“邪惡”或“不邪惡”的精確技術性定義：壓根就沒有。 還有一件事要注意：被稱作“邪惡”的東西（宏、數組、指針等）并非在_所有_情況下_總是_邪惡的。當它們“不是最壞”的選擇時，[就用它們](#%5B6.16%5D)。 ## 6.16有時會用到那些“邪惡”的東西么？ 當然會！ 一種尺寸不可能適用所有情況。停！現在，找個尖頭的筆在你的眼鏡內側寫上：“_軟件開發_就是_做決策_。“思考”(think)不是一個4個字母的單詞。在軟件中很少有“從不”和“總是”之類實施起來不需要動腦子的規則，沒有那些在所有情況下都適用的規則，沒有那種放之四海皆準的規則。 所以最終你_將會_使用那些“邪惡”的技術。如果你覺得這個詞不舒服，那么換成“很多時候不推薦”（不過可別辭職改行當作家：像那種[軟蛋](http://www.dictionary.com/search?q=milquetoast)類型的術語只會讓人睡著:-)。 譯注：這里的“軟蛋”術語指”很多時候不推薦“這種聽上去不夠”硬“的表達。 ## 6.17是否知道這些東西的技術定義很重要：“好的OO”，“好的類設計”？ 可能你不喜歡，但簡短的回答是，“不”（注意這個回答是給實踐者而不是理論家的）。 專業的軟件設計者根據這些來做評估：業務需求（時間，金錢和風險）以及技術需求（例如是不是“好的OO”或“好的類設計”）。這要困難很多，因為除 了技術因素，還涉及到業務問題（期限，人員的技術能力，知道公司的發展方向以便決定如何靈活設計，是否愿意考慮將來可能的變化（指實際可能發生而不只是理 論上可能）等等。）。然而，這樣作出的決策_更加_可能帶來好的效益。 做為一名開發者，你對老板要負有一種信任上的責任，要只投資那種能夠帶來可觀回報的方面。如果除了技術問題之外不再問業務問題，你作出的決策就可能帶來不可預知的商業結果。 不管喜不喜歡，這意味著實際上你可能最好還是不要去定義諸如“好的類設計”和“好的OO”這類術語。實際上我相信這些精確的、純技術的定義可能會非 常危險，可能會浪費公司錢財，最終甚至會把人們的工作也搭進去。聽上去有些夸張，但這是有一個很好的理由的：如果這些術語以一種精確、純技術的方式來定 義，那么開發者可能就會好心辦壞事，而忽略業務上的考慮，因為他們想要達到這些純技術定義的“良好”標準。 _任何_純技術定義的“良好”，例如好的“OO”或“好的設計”或是任何其它不需考慮期限、業務目標（即投資方向）、預期的未來變化、企 業在未來的投資意愿方面的文化、做維護工作的團隊的技術水平等事情的東西，都是危險的。因為這回誘使程序員相信他們做的決定是“正確”的，而實際卻_可能_導致_災難性_后果。或者也可能雖然沒有帶來糟糕的商業后果，但關鍵是：當你在做決定時忽略了業務，那么最終結果會是隨機的，有點無法預期。這就不好了。 事實很簡單，業務問題高于技術問題。任何有關“好”的定義，如果不承認這點，那這個定義就是糟糕的。 ## 6.18當人們抱怨說“FAQ”這個詞太誤導人了，因為它強調問題而不是答案，因此我們需要換一個不同的縮寫詞，這時我應該怎么對他們說？ 告訴他們成長起來。 有人希望能夠把”FAQ“換一個詞，比如要能夠強調答案而不是問題。但單詞或短語是根據其用法來定義的。很多人已經理解了“FAQ”這個詞本身的含義了。最好把它當作是一個名字，而不是縮寫詞。做為一個單詞來說，“FAQ”已經表示一份常見問題_和_答案的列表了。 這并不是鼓勵用詞時不加考慮。相反，關鍵是清晰的交流需要使用人們已經理解的詞匯。爭論我們是否應該為“FAQ”換個詞很蠢，而且浪費時間。如果這個詞還沒有為大家所熟知的話，那就是另外一回事了。但當很多人都已經理解了再去更換，那就沒有意義了。 舉個（不太完美）的類比，大家已經廣泛接受'\n'做為換行符了，可現在仍然有少數程序員和某種計算機打交道，這些計算機有實際“換行”的打字終端。沒人會在乎這個的。這就是個換行符，別在為之煩惱了。同理，'\r'是回車符，即使你的機器沒有這種東西。接受它吧。 另一個（不完美）的類比是RAII。感謝Andy Koenig等人的偉大工作，“RAII”在C++社區已經廣為人知了。“RAII”代表了一種非常有價值的概念，并且你應該經常用它。_但是_，如果你把“RAII”做為一個首字母縮寫詞來分解，并且如果你仔細研究組成這個縮寫詞的各個單詞，你會意識到這些詞并不能完美代表其含義。但誰在乎呢？！？重要的是概念，“RAII”只不過是其背后概念的一個稱呼。 > 細節：如果你把RAII分解成各個單詞（Resource Acquisition Is Initialization獲取資源即初始化），你可能會認為RAII是指在初始化時獲取資源。然而，RAII的威力并非來自將_獲取_和_初始化_綁在一起，而使在于將_回收資源_和_析構_聯 系在一起。更精確的縮寫可能是“RRID”（Resource Reclamation Is Destruction資源回收即析構），或者DIRR（Destruction Is Resource Reclamation析構即回收資源），但既然大家已經廣泛理解了RAII，使用這個詞就比抱怨術語更重要。RAII是一種思想的名稱，其做為一個縮寫 詞的精確性就不那么重要了。 > 所以還是把“FAQ”當作一個名字，其含義已被廣泛接受了。單詞的意義是由其用法定義的。 對應原文最后更新2009年1月2日 翻譯最后更新2009年3月28日