google不使用 c++ 異常，這裡也存在爭議。。。
優點:
缺點:
從表面上看來，使用異常利大於弊, 尤其是在新專案中. 但是對於現有**, 引入異常會牽連到所有相關**. 如果新專案允許異常向外擴散, 在跟以前未使用異常的**整合時也將是個麻煩. 因為 google 現有的大多數 c++ **都沒有異常處理, 引入帶有異常處理的新**相當困難.
鑑於 google 現有**不接受異常, 在現有**中使用異常比在新專案中使用的代價多少要大一些. 遷移過程比較慢, 也容易出錯. 我們不相信異常的使用有效替代方案, 如錯誤**, 斷言等會造成嚴重負擔.
我們並不是基於哲學或道德層面反對使用異常, 而是在實踐的基礎上. 我們希望在 google 使用我們自己的開源專案, 但專案中使用異常會為此帶來不便, 因此我們也建議不要在 google 的開源專案中使用異常. 如果我們需要把這些專案推倒重來顯然不太現實.
對於 windows **來說, 有個特例.
(yulefox 注: 對於異常處理, 顯然不是短短幾句話能夠說清楚的, 以建構函式為例, 很多 c++ 書籍上都提到當構造失敗時只有異常可以處理, google 禁止使用異常這一點, 僅僅是為了自身的方便, 說大了, 無非是基於軟體管理成本上, 實際使用中還是自己決定)
C語言 注釋轉換（C風格 C 風格）
其中有一些檔案操作函式，不懂的可以看這篇部落格 首先，我們要知道乙個檔案中至少有五種狀態，我們用狀態圖表示 解讀 我們從 不是注釋 的狀態開始，請看下圖 有以下幾種情況需要注意 轉變成 轉變成 判斷是否為換行，如果換行需要輸入 轉變成 如果準備出注釋的時候，遇到 先保留看下乙個字元是不是 如果是 在...
c 風格指南
參考 google c 風格指南 ifndef project path file h define project path file h 原始檔中首先包含對應標頭檔案 include 對應標頭檔案 include 禁止使用using namespace foo 而應使用using foo bar...
C 風格經驗
畢竟與c加加共處有一段時間了，對於一些規範，我想提供一些經驗 一些函式沒有返回值最好使用void，更容易看懂。變數和函式要宣告得顧名思義，對於一些迴圈變數不用也罷。為了他人的理解，常量全用大寫是乙個不錯的選擇。複雜一定要加注釋！別人看不懂有意思嗎？過多的注釋讓人眼花繚亂，切記不要過多。在 中不要過多...