近來一篇<The Dark Side Of C++>在坊間廣為轉(zhuǎn)載，作為一個以C++為吃飯家伙的程序員，還是應該下載下來好好讀一讀的?？偟膩碇v還是總結的蠻全的，由于個人知識的限制，我讀完后將其分為三類：一類是我不以為然的，覺得算不上陰暗面；一類是深有同感，深受其害；而另外一類則是還不理解，需要日后有時間的時候加以研究的。

一、不以為然

• 不斷變更的標準，迫使我們需要不斷更新已有代碼。
  作者列出了幾點其實影響并不是很大（循環(huán)變量的scope；頭文件后綴；名字空間）。而且，為了標準的進步，偶爾做出的妥協(xié)也是應該的吧。
• 不斷變更的style，作者舉得例子是：
  

      
  Old and busted:
  for (int i = 0; i < n; i++)
  New hotness:
  for (int i(0); i != n; ++i)
      

    有這個問題嗎？有人用第二種方式的嗎？ 
• auto_ptr很爛。
  這個，你不用它就是了，而且最近在智能指針加入C++0x大家庭后，應該達成共識了吧
• iterator可能會失效。
  這個我感覺還好，沒遇到過太多問題；
• iterator對container毫不知情。
  我覺得這是STL設計的一個優(yōu)點吧，通過iterator解耦算法與容器。
• vector::at會做邊界檢查，而operator []不會。
  很好啊，提供兩種選擇
• 構造函數(shù)與析構函數(shù)中的虛函數(shù)調(diào)用，可能會調(diào)用基類的虛函數(shù)，甚至是純虛函數(shù)。
  這個不怎么陰暗吧，不要在構造函數(shù)與析構函數(shù)總調(diào)用虛函數(shù)應該是個常識，而且，其他語言難道沒有這個問題？

二、深有同感

• 模板中排山倒海式的編譯錯誤，在繁瑣無比的錯誤后面，原因可能僅僅是用錯了iterator類型。那個被斃掉的C++ 0x proposal不知是否可以解決此問題。
• 用C++寫的代碼不太容易讀，函數(shù)重載，操作符重載，虛函數(shù)重定義，類型重定義，宏定義等等，把代碼的真實面貌嚴嚴實實的藏在了身后。（當然，這也是為了抽象與一致性），幾個例子：
  

      
  string a("blah"); // 定義一個string對象
  string a(); //聲明一個函數(shù)
  
  a && b // 如果&&沒被重定義，是短路計算；但若是被重載了，那么可能兩個都要計算
  
  typedef OtherType& Type;
  Type a = b;
  a.value = 23; // 不看到那個typedef，鬼知道b的值會不會被改掉
      

  
   另外， baz = foo->bar(3)；如此簡單的一行代碼背后蘊含的無窮可能，也充分體現(xiàn)了C++代碼難讀的特點。
• 關于cin為什么typecast到void*，而不是bool的討論，凸顯了C++中劍走偏鋒的情況 - 火候不到，一招不慎就很容易傷及自身。
• 析構函數(shù)中不應該拋出異常，我以前只知道一個原因 - 就是在前次異常的棧展開過程中調(diào)用析構函數(shù)并拋出異常，會導致程序退出。但這里給出了我覺得更有說服力的原因：在delete []數(shù)組的時候，前面對象析構拋出異常，會導致數(shù)組中其他對象內(nèi)存泄露。
• 類成員的初始化順序由其定義的順序決定，而不是初始化列表中的順序 - 這點的確引起了較大的迷惑，也帶來了不少bug - 因為C++的行為是反直覺的。
• 函數(shù)調(diào)用中，傳指針的方式比較明顯的告訴你該函數(shù)可能會改變這個參數(shù)，而引用卻沒這么明顯，語法和傳值調(diào)用一樣，卻也可以改變參數(shù)值。
• C++過于強大，過于靈活，很多人無法很好的掌控 - 太多復雜的feature set，要用好它，你可以讀個博士了~~~
• prefix ++的重載語法是：operator++(yourtype&)， 為了加以區(qū)別，postfix的重載語法有個dummy的int參數(shù)：operator++(yourtype&, int dummy)。
  雖然我也沒有更好的方法，但我承認這的確很傻。
• 同樣的容器，由于使用了不同的allocator就無法交互了，這可以理解，因為STL中allocator是容器類型的一部分，allocator不同導致容器類型不同 - 但這不得不讓我們思考STL用這種方式提供allocator是不是合適。
• map的operator[]自動添加元素，如果不存在的話。
  因為相比于find和insert，operator []實在是太方便了，這個方便的誘惑的確造成了不少麻煩。
• 模板中你不得不把>>寫成> >。因為>>已經(jīng)被占用了。
• 用不用exception，如何用好exception實在是個太大太深的話題，都可以在大學開個博士學位了。其中異常安全中resource leak，deadlock是常見的問題。
• delete []可以很好的處理退化為指針的數(shù)組，如果是類的話調(diào)用會調(diào)用的析構函數(shù)s，因為數(shù)組元素的個數(shù)可以通過sizeof(memoryblock)/sizeof(type)求出。
• new []可能會引起int的溢出，如: new double [0x8000000] = malloc (8 * 0x80000000)，超過了int的表達范圍，溢出~
• 局部靜態(tài)變量的初始化不是線程安全的 - 這個問題在多線程環(huán)境下的單件模式中尤為常見，一般可以用lock解決，但是每次訪問都lock比較費力，所以會用一種double-check lock的方式，但是這種方式由于編譯器優(yōu)化引起的reorder，也會線程不安全，需要使用volatile，或者memory barrier防止優(yōu)化。這個估計可以另外寫篇文章了。
• 用基類指針操作派生類的數(shù)組，p++不是指向下一個元素，而是指向了一個不合適的內(nèi)存地址。
• 如果你在派生類中有個函數(shù)的名字和基類中的函數(shù)名字重復，即使函數(shù)原型不一樣，其基類中的函數(shù)都將在派生類中被隱藏。
  這點的確比較過分！背后有什么原因呢？ 

三、日后研究

• 關于名字空間，C++有過什么大的更改么？
  這個估計要查查《C++語言的設計與演化》了
• 用C++寫出好的庫基本是不可能的。
  我看到很多人，包括牛人都說過這個，但是不知有沒有給過一個列表，C++中那些缺點使其寫出好的庫成為不可能，哪些語言可以，為什么？
• 我們不應該在構造函數(shù)中拋出異常，因為：Exceptions in constructor don’t unwind the constructor itself。
  這個不太理解，據(jù)我所知，在構造函數(shù)中拋出異常是構造函數(shù)報錯的一個方法，因為構造函數(shù)本身不返回任何值。
• 拋出異常時：Does not even clean up local variables！
  不理解，我們的RTTI不就是利用local對象的析構來做內(nèi)存管理的嗎。
• assert(s[s.size()] == 0); works if s is a const std::string, butis unde?ned if it is not const
  在VC2008上試了一下，沒問題。為什么會這么說，為什么？ 
• If you call delete when you should have called delete[], the pointer wilbe off by sizeof(int), leading to heap corruption and possibly code execution.
  不懂。
• If you call delete[] when you should have called delete, some randomdestructors will be called on garbage data, probably leading to code execution.
  為什么，delete[]會去計算該數(shù)組中有幾個元素，而答案應該是1，那就不該有問題 - 這個可能和上一點的答案有關。