第一部分 語法篇

?

第1章???從C繼承而來的

建議0：不用讓main函數返回void

???????? main函數的返回類型是int，不是void或其它類型。

建議1：區分0的4種面孔

?????????(1)、整型0；(2)、空指針NULL，指針與int類型所占空間是一樣的，都是32位；(3)、字符串結束標志’\0’；(4)、邏輯FALSE/false，FALSE/TRUE是int類型，而false/true是bool類型。

建議2：避免那些由運算符引發的混亂

???????? 不要混淆=和==、&和&&、|與||這三對運算符之間的差別，針對=和==之間的問題，可以這樣做：if (0 == nValue)。

建議3：對表達式計算順序不用想當然

?????????(1)、針對操作符優先級，建議多寫幾個括號；(2)、注意函數參數和操作數的評估求值順序問題。

建議4：小心宏#define使用中的陷阱

?????????(1)、用宏定義表達式時，要使用完備的括號：如 #define ADD(a, b) ((a)+(b))；(2)、使用宏時，不允許參數發生變化；(3)、用大括號將宏所定義的多條表達式括起來。

建議5：不要忘記指針變量的初始化

?????????(1)、可以將其初始化為空指針0(NULL)；(2)、對于全局變量來說，在聲明的同時，編譯器會悄悄完成對變量的初始化。

建議6：明晰逗號分隔表達式的奇怪之處

?????????(1)、在使用逗號分隔表達式時，C++會確保每個表達式都被執行，而整個表達式的值則是最右邊表達式的結果；(2)、在C++中，逗號分隔表達式既可以用作左值，也可以用作右值。

建議7：時刻提防內存溢出

?????????在調用C語言字符串金典函數(strcpy、strcat、gets等)時，要從源代碼開始就提高警惕，盡量追蹤傳入數據的流向，向代碼中的每一個假設提出質疑。在訪問數據時，注意對于邊界數據要特殊情況特殊處理，還要對杜絕使用未初始化指針和失敗后未置NULL的“野指針”。

建議8：拒絕晦澀難懂的函數指針

???????? 函數指針在運行時的動態調用(例如函數回調)中應用廣泛。但是直接定義復雜的函數指針會由于有太多的括號而使代碼的可讀性下降。使用typedef可以讓函數指針更直觀和易維護。

建議9：防止重復包含頭文件

???????? 為了避免重復包含頭文件，建議在聲明每個頭文件時采用“頭文件衛士”加以保護，比如采用如下的形式：

#ifndef__SOMEFILE_H__#define__SOMEFILE_H__……//聲明、定義語句#endif

建議10：優化結構體中元素的布局

?????????把結構體中的變量按照類型大小從小到大依次聲明，盡量減少中間的填充字節。

建議11：將強制轉型減到最少

???????? (1)、const_cast<T*>(a)：它用于從一個類中去除以下這些屬性：const、volatile和__unaligned；(2)、dynamic_cast<T*>(a)：它將a值轉換成類型為T的對象指針，主要用來實現類層次結構的提升；(3)、reinterpret_cast<T*>(a)：它能夠用于諸如One_class*到Unrelated_class*這樣的不相關類型之間的轉換，因此它是不安全的；(4)、static_cast<T*>(a)：它將a的值轉換為模板中指定的類型T，但是，在運行時轉換過程中，它不會進行類型檢查，不能確保轉換的安全性。

建議12：優先使用前綴操作符

?????????對于整型和長整型的操作，前綴操作和后綴操作的性能區別通常是可以忽略的。對于用戶自定義類型，優先使用前綴操作符。因為與后綴操作符相比，前綴操作符因為無須構造臨時對象而更具性能優勢。

建議13：掌握變量定義的位置與時機

?????????在定義變量時，要三思而后行，掌握變量定義的時機與位置，在合適的時機于合適的位置上定義變量。盡可能推遲變量的定義，直到不得不需要該變量為止；同時，為了減少變量名污染，提高程序的可讀性，盡量縮小變量的作用域。

建議14：小心typedef使用中的陷阱

???????? 區分typedef與#define之間的不同；不要用理解宏的思維方式對待typedef，typedef聲明的新名稱具有一定的封裝性，更易定義變量。同時還要注意它是一個無“現實意義”的存儲類關鍵字。

建議15：盡量不要使用可變參數

?????????編譯器對可變參數函數的原型檢查不夠嚴格，所以容易引起問題，難于查錯，不利于寫出高質量的代碼。所以應當盡量避免使用C語言方式的可變參數設計，而用C++中更為安全的方式來完美代替之(如多態等)。

建議16：慎用goto

?????????過度使用goto會使代碼流程錯綜復雜，難以理清頭緒。所以，如果不熟悉goto，不要使用它；如果已經習慣使用它，試著不去使用。

建議17：提防隱式轉換帶來的麻煩

?????????提防隱式轉換所帶來的微妙問題，盡量控制隱式轉換的發生；通常采用的方式包括：(1)、使用非C/C++關鍵字的具名函數，用operator as_T()替換operator T()(T為C++數據類型)。(2)、為單參數的構造函數加上explicit關鍵字。

建議18：正確區分void與void*

?????????Void是“無類型”，所以它不是一種數據類型；void*則為“無類型指針”，即它是指向無類型數據的指針，也就是說它可以指向任何類型的數據。Void發揮的真正作用是限制程序的參數與函數返回值：(1)、如果函數沒有返回值，那么應將其聲明為void類型；(2)、如果函數無參數，那么聲明函數參數為void。對于void*，(1)、任何類型的指針都可以直接賦值給它，無須強制轉型；(2)、如果函數的參數可以是任意類型指針，那么應聲明其參數為void*。

?

第2章???從C到C++，需要做出一些改變

建議19：明白在C++中如何使用C

???????? 若想在C++中使用大量現成的C程序庫，就必須把它放到extern“C” {/* code */}中，extern “C”的作用就是告訴C++鏈接器尋找調用函數的符號時，采用C的方式。要實現在C++代碼中調用C的代碼，具體方式有以下幾種：(1)、修改C代碼的頭文件，當其中含有C++代碼時，在聲明中加入extern “C”；(2)、在C++代碼中重新聲明一下C函數，在重新聲明時添加上extern “C”；(3)、在包含C頭文件時，添上extern “C”。

建議20：使用memcpy()系列函數時要足夠小心

?????????要區分哪些數據對象是POD(傳統C風格的數據類型，C的所有對象都是POD，對于任何POD對象，我們都可以放心大膽地使用memset()、memcpy()、memcmp()等函數對對象的內存數據進行操作)，哪些是非POD(C++的對象可能并不是一個POD，如動多態)，由于非POD對象的存在，在C++中使用memcpy()系列函數時要保持足夠的小心。

建議21：盡量用new/delete代替malloc/free

?????????malloc與new之間的區別：(1)、new是C++運算符，而malloc則是C標準庫函數；(2)、通過new創建的東西是具有類型的，而malloc函數返回的則是void*，需要進行強制轉型；(3)、new可以自動調用對象的構造函數，而malloc不會；(4)、new失敗是會調用new_handler處理函數，而malloc失敗則直接返回NULL。Free與delete之間的區別：(1)、delete是C++運算符，free是C標準庫函數；(2)、delete可以自動調用對象的析構函數，而malloc不會。另外，new/delete必須配對使用，malloc/free也一樣。

建議22：靈活地使用不同風格的注釋

?????????C風格的注釋/* */與C++風格的注釋//在C++語言中同時存在。

建議23：盡量使用C++標準的iostream

?????????建議使用#include <iostream>

建議24：盡量采用C++風格的強制轉型

建議25：盡量用const、enum、inline替換#define

?????????對于簡單的常量,應該盡量使用const對象或枚舉類型數據，避免使用#define；對于形似函數的宏，盡量使用內聯函數，避免使用#define。總之一句話，盡量將工作交給編譯器，而不是預處理器。

建議26：用引用代替指針

?????????與指針不同，引用與地址沒有關聯，甚至不占任何存儲空間。

?

第3章???說一說“內存管理”的那點事兒

在VC中，棧空間未初始化的字符默認是-52，補碼是0xCC，兩個0xCC，即0xCCCC在GBK編碼中就是“燙”；堆空間未初始化的字符默認是-51，兩個-51在GBK編碼中就是“屯”。兩者都是未初始化的內存。

?

建議27：區分內存分配的方式

?????????一個程序要運行，就必須先將可執行的程序加載到計算機內存里，程序加載完畢后，就可以形成一個運行空間，按照代碼區、數據區、堆區、棧區進行布局。代碼區存放的是程序的執行代碼；數據區存放的是全局數據、常量、靜態變量等；堆區存放的則是動態內存，供程序隨機申請使用；而棧區則存放著程序中所用到的局部數據。這些數據可以動態地反應程序中對函數的調用狀態，通過其軌跡也可以研究其函數機制。

???????? 在C++中，數據區又被分成自由存儲區、全局/靜態存儲區和常量存儲區，再加上堆區、棧區，也就是說，內存被分成了5個區。(1)、棧區：在執行函數時，函數內局部變量的存儲單元都可以在棧上創建，函數執行結束時這些存儲單元將自動被釋放。棧內存分配運算內置于處理器的指令集中，效率很高，但是所分配的內存容量有限；(2)、堆區：堆就是那些由new分配的內存塊，其釋放編譯器不會管它，而是由我們的應用程序控制它，一般一個new就對應于一個delete，如果程序員沒有釋放掉，那么在程序結束后，操作系統就會自動回收；(3)、自由存儲區：是那些由malloc等分配的內存塊，它和堆十分相似，不過它是用free來結束自己生命的；(4)、全局/靜態存儲區：全局變量和靜態變量被分配到同一塊內存中，在以前的C語言中，全局變量又分為初始化的和未初始化的，在C++里面沒有作此區分，它們共同占用同一塊內存區；(5)、常量存儲區：這是一塊比較特殊的存儲區，里面存放的是常量，不允許修改。

???????? 堆與棧的區別：(1)、管理方式不同：對于棧來講，它是由編譯器自動管理的，無須我們手工控制；對于堆來說，它的釋放工作由程序員控制，容易產生memory leak；(2)、空間大小不同：一般來講在32位系統下，堆內存可以達到4GB的空間，從這個角度來看堆內存幾乎是沒有什么限制的。但是對于棧來講，一般都是有一定空間大小的；(3)、碎片問題：對于堆來講，頻繁的new/delete勢必會造成內存空間的不連續，從而產生大量的碎片，使程序效率降低。對于棧來講，則不存在這個問題，其原因還要從棧的特殊數據結構說起。棧是一個具有嚴明紀律的隊列，其中的數據必須遵循先進后出的規則，相互之間緊密排列，絕不會留給其他數據可插入之空隙，所以永遠都不可能有一個內存塊從棧中間彈出，它們必須嚴格按照一定的順序一一彈出；(4)、生成方向：對于堆來講，其生長方向是向上的，也就是向著內存地址增加的方向增長；對于棧來講，它的生長方向是向下的，是向著內存地址減小的方向增長的；(5)、分配方式：堆都是動態分配的，沒有靜態分配的堆。棧有兩種分配方式：靜態分配和動態分配。靜態分配是編譯器完成的，比如局部變量的分配。動態分配由alloca函數完成，但是棧的動態分配和堆是不同的，它的動態分配是由編譯器進行釋放的，無須我們手工實現；(6)、分配效率：棧是機器系統提供的數據結構，計算機會在底層對棧提供支持：它會分配專門的寄存器存放棧的地址，而且壓棧出棧都會有專門的指令來執行，這就決定了棧的效率比較高。堆則是C/C++函數庫提供的，它的機制很復雜，例如為了分配一塊內存，庫函數會按照一定的算法在堆內存中搜索可用的足夠大小的空間，如果沒有足夠大小的空間(可能是由于內存碎片太多)，則可能調用系統功能去增加程序數據段的內存空間，這樣就有機會分到足夠大小的內存了，然后返回。顯然，堆的效率比棧要低得多。

建議28：new/delete與new[]/delete[]必須配對使用

?????????由于內置數據類型沒有構造、析構函數，所以在針對內置數據類型時，釋放內存使用delete或delete[]的效果都是一樣的。

建議29：區分new的三種形態

???????? (1)、如果是在堆上建立對象，那么應該使用new operator，它會為你提供最為周全的服務；(2)、如果僅僅是分配內存，那么應該調用operator new，但初始化不在它的工作職責之內。如果你對默認的內存分配過程不滿意，想單獨定制，重載operator new是不二選擇；(3)、如果想在一塊已經獲得的內存里建立一個對象，那就應該用placement new。但是通常情況下不建議使用，除非是在某些對時間要求非常高的應用中，因為相對于其他兩個步驟，選擇合適的構造函數完成對象初始化是一個時間相對較長的過程。

建議30：new內存失敗后的正確處理

?????????當使用new申請一塊內存失敗時，拋出異常std::bad_alloc是C++標準中規定的標準行為，所以推薦使用try{p=new int[SIZE];} catch(std::bad_alloc) {…} 的處理方式。但是在一些老舊的編譯器中，卻不支持該標準，它會返回NULL，此時具有C傳統的Test_for_NULL代碼形式便起了作用。所以，要針對不同的情形采取合理的處置方式。

建議31：了解new_handler的所作所為

???????? 在使用operatornew申請內存失敗后，編譯器并不是不做任何的努力直接拋出std::alloc異常，在這之前，它會調用一個錯誤處理函數(這個函數被稱為new-handler)，進行相應的處理。通常，一個好的new-handler函數的處理方式必須遵循以下策略之一：(1)、使更大塊內存有效；(2)、裝載另外的new-handler；(3)、卸載new-handler；(4)、拋出異常；(5)、無返回。

建議32：借助工具檢測內存泄露問題

?????????內存泄露一般指的是堆內存的泄露。檢測內存泄露的關鍵是能截獲對分配內存和釋放內存的函數的調用。通過截獲的這兩個函數，我們就能跟蹤每一塊內存的生命周期。每當成功分配一塊內存時，就把它的指針加入一個全局的內存鏈中；每當釋放一塊內存時，再把它的指針從內存鏈中刪除。這樣當程序運行結束的時候，內存鏈中剩余的指針就會指向那些沒有被釋放的內存。這就是檢測內存泄露的基本原理。

???????? 檢測內存泄露的常用方法有如下幾種：(1)、MS C-Runtime Library內建的檢測功能，要在非MFC程序中打開內存泄露的檢測功能非常容易，只須在程序的入口處添加以下代碼：

_CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG)| _CRTDBG_LEAK_CHECK_DF);

(2)、外掛式的檢測工具：MS下BoundsChecker或Insure++；Linux下RationalPurify或Valgrind.

建議33：小心翼翼地重載operator new/operator delete

?????????通過重載operator new 和 operatordelete的方法，可以自由地采用不同的分配策略，從不同的內存池中分配不同的類對象。但是是否選擇重載operator new/delete 一定要深思熟慮。

建議34：用智能指針管理通過new創建的對象

?????????智能指針auto_ptr，要使用它，需要包含memory頭文件：(1)、auto_ptr對象不可作為STL容器的元素；(2)、auto_ptr缺少對動態配置而來的數組的支持；(3)、auto_ptr在被復制的時候會發生所有權轉移。

建議35：使用內存池技術提高內存申請效率與性能

?????????經典的內存池技術，是一種用于分配大量大小相同的小對象的技術。通過該技術可以極大地加快內存分配/釋放過程。內存池技術通過批量申請內存，降低了內存申請次數，從而節省了時間。

?

第4章???重中之重的類

建議36：明晰class與struct之間的區別

?????????C中的struct是一種數據類型。C++中struct被看成是一個對象，它可以包含函數，可以擁有構造函數、析構函數，同樣擁有繼承等能力。

???????? C++中的class與struct差別：(1)、class和struct如果定義了構造函數，就都不能用大括號進行初始化了；如果沒有定義，struct可以用大括號初始化，而class只有在所有成員變量全是public的情況下，才可以用大括號進行初始化；(2)、關于默認訪問權限：class中默認的成員訪問權限是private的，而struct中則是public的；(3)、關于繼承方式：class繼承默認是private繼承，而struct默認是public繼承

建議37：了解C++悄悄做的那些事

???????? 對于類，編譯器會悄悄地完成很多事：隱士產生一個類的默認構造函數，拷貝構造函數，拷貝賦值運算符和析構函數。

建議38：首選初始化列表實現類成員的初始化

?????????類成員的初始化可采用兩種形式來完成：在構造函數體重賦值完成和用初始化類成員列表完成：(1)、const成員變量只能用成員初始化列表來完成初始化，而不能在構造函數內被賦值；(2)、如果類B中含有A類型的成員變量，而類A中又禁止了賦值操作，此時要想順利地完成B中成員變量的初始化，就必須采用初始化列表方式。即使沒有禁用賦值操作，還是不推薦采用函數體內的賦值初始化方式。因為這種方式存在著兩種問題。第一，比起初始化列表，此方式效率偏低；第二，留有錯誤隱患。

???????? 對于初始化列表，初始化的順序與構造函數中的賦值方式不同，初始化列表中成員變量出現的順序并不是真正初始化的順序，初始化的順序取決于成員變量在類中的聲明順序。只有保證成員變量聲明的順序與初始化列表順序一致才能真正保證其效率。

建議39：明智地拒絕對象的復制操作

?????????在某些需要禁止對象復制操作的情形下，可以將這個類相應的拷貝構造函數、賦值操作符operator = 聲明為private，并且不要給出實現。或者采用更簡單的方法：使用boost::noncopyable作為基類。

建議40：小心，自定義拷貝函數

?????????如果類內部出現了動態配置的資源，我們就不得不自定義實現其拷貝函數了。在自定義拷貝函數時，應該保證拷貝一個對象的All Parts:所有數據成員及所有的基類部分。

建議41：謹防因構造函數拋出異常而引發的問題

?????????判斷構造對象成功與否，解決辦法：拋出一個異常。構造函數拋出異常會引起對象的部分構造，因為不能自動調用析構函數，在異常發生之前分配的資源將得不到及時的清理，進而造成內存泄露問題。所以，如果對象中涉及了資源分配，一定要對構造之中可能拋出的異常做謹慎而細致的處理。

建議42：多態基類的析構函數應該為虛

?????????虛函數的最大目的就是允許派生類定制實現。所以，用基類指針刪除一個派生類對象時，C++會正確地調用整個析構鏈，執行正確的行為，以銷毀整個對象。在實際使用虛析構函數的過程中，一般要遵守以下規則：當類中包含至少一個虛函數時，才將該類的析構函數聲明為虛。因為一個類要作為多態基類使用時，它一定會包含一個需要派生定制的虛函數。相反，如果一個類不包含虛函數，那就預示著這個類不能作為多態基類使用。同樣，如果一個類的析構函數非虛，那你就要頂住誘惑，決不能繼承它，即使它是“出身名門”。比如標準庫中的string、complex、以及STL容器。

???????? 多態基類的析構函數應該是virtual的，也必須是virtual的，因為只有這樣，虛函數機制才會保證派生類對象的徹底釋放；如果一個類有一個虛函數，那么它就該有一個虛析構函數；如果一個類不被設計為基類，那么這個類的析構就應該拒絕為虛。

建議43：絕不讓構造函數為虛

?????????虛函數的工作機制：虛函數的多態機制是通過一張虛函數表來實現的。在構造函數調用返回之前，虛函數表尚未建立，不能支持虛函數機制，所以構造函數不允許設為虛。

建議44：避免在構造/析構函數中調用虛函數

?????????成員函數、包括虛成員函數，都可以在構造、析構的過程中被調用。當一個虛函數被構造函數(包括成員變量的初始化函數)或者析構函數直接或間接地調用時，調用對象就是正在構造或者析構的那個對象。其調用的函數是定義于自身類或者其基類的函數，而不是其派生類或者最低派生類的其他基類的重寫函數。

如果在構造函數或析構函數中調用了一個類的虛函數，那它們就變成普通函數了，失去了多態的能力。

建議45：默認參數在構造函數中給你帶來的喜與悲

?????????合理地使用默認參數可以有效地減少構造函數中的代碼冗余，讓代碼簡潔而有力。但是如果不夠小心和謹慎，它也會帶來構造函數的歧義，增加你的調試時間。

建議46：區分Overloading、Overriding、Hiding之間的差異

?????????1、重載(Overloading)：是指同一作用域的不同函數使用相同的函數名，但是函數的參數個數或類型不同；2、重寫(Overriding)：是指在派生類中對基類中的虛函數重新實現，即函數名和參數都一樣，只是函數的實現體不一樣，派生類對基類中的操作進行個性化定制就是重寫。重寫需要注意的問題：(1)、函數的重寫與訪問層級(public、private、protected)無關；(2)、const可能會使虛成員函數的重寫失效；(3)重寫函數必須和原函數具有相同的返回類型；3、隱藏(Hiding)：是指派生類中的函數屏蔽基類中具有相同名字的非虛函數。

建議47：重載operator=的標準三步走

?????????1、不要讓編譯器幫你重載賦值運算符；2、一定要檢查自賦值；3、賦值運算符重載需返回*this的引用，引用之于對象的優點在于效率，為了能夠更加靈活地使用賦值運算符，選擇返回引用絕對是明智之舉；4、賦值運算符重載函數不能被繼承。如果需要給類的數據成員動態分配空間，則必須實現賦值運算符。

建議48：運算符重載，是成員函數還是友元函數

?????????運算符重載的四項基本原則：(1)、不可臆造運算符；(2)、運算符原有操作數的個數、優先級和結合性不能改變；(3)、操作數中至少一個是自定義類型；(4)、保持重載運算符的自然含義。

???????? 運算符的重載可采用兩種形式：成員函數形式和友元函數形式。(1)、重載為成員函數時，已經隱含了一個參數，它就是this指針；對于雙目運算符，參數僅有一個；(2)、當重載友元函數時，將不存在隱含的參數this指針；如果運算符被重載為友元函數，那么它就獲得一種特殊的屬性，能夠接受左參數和右參數的隱式轉換，如果是成員函數版的重載則只允許右參數的隱式轉換。一般說來，建議遵守一個不成文的規定：對雙目運算符，最好將其重載為友元函數，因為這樣更方便些；而對于單目運算符，則最好重載為成員函數。

建議49：有些運算符應該成對實現

???????? 為了更好地適應使用習慣，很多運算符重載時最好成對實現，比如==與!=、<與>、<=與>=、+與+=、-與-=、*與*=、/與/=。

建議50：特殊的自增自減運算符重載

?????????后綴操作重載時返回值應該為一個const對象。

建議51：不要重載operator&&、operator||以及operator,

?????????“&&”、“||”、“,”(逗號運算符)都具有較為特殊的行為特性，重載會改變運算符的這些特性，進而影響原有的習慣，所以不要去重載這三個可以重載的運算符。

建議52：合理地使用inline函數來提高效率

?????????內聯函數具有與宏定義相同的代碼效率，但在其他方面卻要優于宏定義。因為內聯函數還遵循函數的類型和作用域規則。內聯函數一般情況下都應該定義在頭文件中。內聯函數的定義分為兩種方式：(1)、顯示方式：在函數定義之前添加inline關鍵字，內聯函數只有和函數體聲明放在一起時inline關鍵字才具有效力；(2)、隱式方式：將函數定義于類的內部。一個給定的函數是否得到內聯，很大程度上取決于你正在使用的編譯器。

???????? 使用內聯函數應該注意：(1)、內聯函數的定義必須出現在內聯函數第一次被調用之前。所以，它一般會置于頭文件中；(2)、在內聯函數內不允許用循環語句和開關語句，函數不能過于復雜；(3)、依據經驗，內聯函數只適合于只有1~5行的小函數；(4)、對于內存空間有限的機器而言，慎用內聯。過分地使用內聯會造成函數代碼的過度膨脹，會占用太多空間；(5)、不要對構造/析構函數進行內聯；(6)、大多開發環境不支持內聯調試，所以為了調試方便，不要將內聯優化放在調試階段之前。

建議53：慎用私有繼承

?????????私有繼承會使基類的所有東西(包括所有的成員變量與成員函數)在派生類中變成private的，也就是說基類的全部在派生類中都只能作為實現細節，而不能成為接口。私有繼承意味著“只有implementation 應該被繼承，interface應該被忽略”，代表著是“is-implemented-in-terms-of”的內在關系。通常情況下，這種關系可以采用組合的方式來實現，并提倡優先使用組合的方案。但是如果存在虛函數和保護成員，就會使組合方案失效，那就應使用私有繼承。

建議54：抵制MI的糖衣炮彈

?????????MI(多重繼承)意味著設計的高復雜性、維護的高難度性，盡量少使用MI。

建議55：堤防對象切片

?????????多態的實現必須依靠指向同一類族的指針或引用。否則，就可能出現著名的對象切片(Object Slicing)問題。所以，在既有繼承又有虛函數的情況下，一定要提防對象切片問題。

建議56：在正確的場合使用恰當的特性

?????????(1)、虛函數：虛函數機制的實現是通過虛函數表和指向虛函數表的指針來完成的。關鍵字virtual告訴編譯器該函數應該實現晚綁定，編譯器對每個包含虛函數的類創建虛函數表VTable，以放置類的虛函數地址。編譯器密碼放置了指向虛函數表的指針VPtr，當多態調用時，它會使用VPtr在VTable表中查找要執行的函數地址；(2)、多重繼承：對于多重繼承來說，對象內部會有多個VPrt，所以這就使偏移量計算變得復雜了，而且會使對象占用的空間和運行時開銷都變大；(3)、虛基類：它與多重繼承的情況類似，因為虛基類就是為了多重繼承而產生的；(4)、運行時類型檢測(RTTI)：是我們在程序運行時得到對象和類有關信息的保證。

建議57：將數據成員聲明為private

?????????將數據成員聲明為private是具有相當充分的理由的：(1)、實現數據成員的訪問控制；(2)、在將來時態下設計程序，為之后的各種實現提供彈性；(3)、保持語法的一致性。

建議58：明晰對象的構造與析構的順序

?????????(1)、對象的構造都是從類的最根處開始的，由深及淺，先基類后子類，層層構造，這個順序不能改變。如果含有多個基類，那么就按照聲明順序由前及后執行。析構函數則嚴格按照構造的逆序執行；(2)、成員對象構造函數的調用順序與成員對象的聲明順序嚴格一致，析構順序是構造順序的嚴格逆序。這是因為類的聲明是絕對唯一的，而類的構造函數可以有多個，所以按照聲明才會使析構函數得到唯一的逆序；(3)、如果繼承遇到成員對象，基類構造函數依然會被首先調用，然后調用成員對象的構造函數。

建議59：明了如何在主調函數啟動前調用函數

?????????如果想在主程序main啟動之前調用某些函數，調用全局對象的構造函數絕對是一個很不錯的方法。因為從概念上說，全局對象是在程序開始前已經完成了構造，而在程序執行之后才會實施析構。

?

第5章???用好模板，向著GP(泛型編程)開進

建議60：審慎地在動、靜多態之間選擇

???????? 虛函數機制配合繼承機制，生效于運行期，屬于晚綁定，是動多態；而模板將不同的行為和單個泛化記號相關聯發生在編譯期，屬于早綁定，被稱為靜多態。(1)、動多態：它的技術基礎是繼承機制和虛函數，它在繼承體系之間通過虛函數表來表達共同的接口；(2)、靜多態：它的技術基礎是模板。與動多態相比，靜多態始終在和參數“較勁兒”，它適用于所有的類，與虛函數無關。從應用形式上看，靜多態是發散式的，讓相同的實現代碼應用于不同的場合；動多態是收斂式的，讓不同的實現代碼應用于相同的場合。從思維方式上看，前者是泛型式編程風格，它看重的是算法的普適性；后者是對象式編程風格，它看重的是接口與實現的分離度。兩者區別：(1)、動多態的函數需要通過指針或引用傳參，而靜多態則可以傳值、傳指針、傳引用等，“適應性”更強；(2)、在性能上，靜多態優于動多態，因為靜多態無間接訪問的迂回代碼，它是單刀直入的；(3)、因為實現多態的先后順序不同，所以如果出現錯誤，它們拋出錯誤的時刻也不一樣，動多態會在運行時報錯，而靜多態則在編譯時報錯。

建議61：將模板的聲明和定義放置在同一個頭文件里

?????????模板類型不是一種實類型，它必須等到類型綁定后才能確定最終類型，所以在實例化一個模板時，必須要能夠讓編譯器“看到”在哪里使用了模板，而且必須要看到模板確切的定義，而不僅僅是它的聲明，否則將不能正常而順利地產生編譯代碼。函數模板、類模板不同于一般的函數、類，它們不能像一般的方式那樣進行聲明與定義，標準要求模板的實例化與定義體必須放在同一翻譯單元中。實現這一目標有三種方法(將模板的聲明和定義都放置在同一個.h文件中；按照舊有的習慣性做法來處理，聲明是聲明，實現是實現，二者相互分離，但是需要包含頭文件的地方做一些改變，如，在使用模板時，必須用#include “Temp.cpp”替換掉#include “Temp.h”；使用關鍵字export來定義具體的模板類對象和模板函數)，但是最優策略還是：將模板的聲明和定義都放置在同一個.h文件中，雖然在某種程度上這破壞了代碼的優雅性。

建議62：用模板替代參數化的宏函數

?????????參數化的宏函數有著兩個致命缺點：(1)、缺乏類型檢查；(2)、有可能在不該進行宏替換的時候進行了替換，違背了作者的意圖。模板是實現代碼復用的一種工具，它可以實現類型參數化，達到讓代碼真正復用的目的。

建議63：區分函數模板與模板函數、類模板與模板類

?????????函數模板的重點在于“模板”兩個字，前面的“函數”只是一個修飾詞。其表示的是一個專門用來生產函數的模板。而模板函數重點在“函數”，表示的是用模板所生成的函數。函數模板的一般定義形式為：

???????? Template<class數據類型參數標識符>

???????? 返回類型標識符 函數名(數據類型參數標識符 形參)

???????? {? //… …}

???????? 將函數模板的模板參數實例化后會生成具體的函數，此函數就是模板函數。由函數模板所生成的模板函數的一般形式為：

???????? 函數名<數據類型參數標識符>(數據類型參數標識符 形參)

???????? 類模板是為類定義的一種模式，它使類中的一些數據成員和成員函數的參數或返回值可以取任意的數據類型。在類定義中，凡是采用標準數據類型的數據成員、成員函數的參數前面都要加上類型標識符，在返回類型前也要進行同樣的處理。如果類中的成員函數要在類的聲明之外定義，則它必須是模板函數。將類模板的模板參數實例化后生成的具體類，就是模板類。函數模板和類模板處于實例化之前，而模板函數或模板類則在實例化之后。

建議64：區分繼承與模板

?????????模板的長處在于處理不同類型間“千篇一律”的操作。相較于類繼承，這些類不必具有什么相同的性質。

?

第6章???讓神秘的異常處理不再神秘

建議65：使用exception來處理錯誤

?????????異常能：(1)、增強程序的健壯性；(2)、使代碼變得更簡潔優美、更易維護；(3)、錯誤信息更靈活、豐富。

建議66：傳值throw異常，傳引用catch異常

?????????throw byvalue, catch by reference

建議67：用“throw;”來重新拋出異常

?????????對于異常的重新拋出，需要注意：(1)、重新拋出的異常對象只能出現在catch塊或catch調用的函數中；(2)、如果在處理代碼不執行時碰到“throw ;”語句，將會調用terminate函數。

建議68：了解異常捕獲與函數參數傳遞之間的差異

?????????異常與函數參數的傳遞之間差異：(1)、控制權；(2)、對象拷貝的次數；(3)、異常類型轉換；(4)、異常類型匹配。

建議69：熟悉異常處理的代價

?????????異常處理在帶來便利的同時，也會帶來時間和空間上的開銷，使程序效率降低，體積增大，同時會加大代碼調試和管理的成本。

建議70：盡量保證異常安全

?????????如果采用了異常機制，請盡量保證異常安全：努力實現強保證，至少實現基本保證。

?

第7章???用好STL這個大輪子

建議71：盡量熟悉C++標準庫

?????????C++標準庫主要包含的組件：(1)、C標準函數庫；(2)、輸入/輸出(input/output)；(3)、字符串(string)；(4)、容器(containers)；(5)、算法(algorithms)；(6)、迭代器(iterators)；(7)、國際化(internationalization)；(8)、數值(numerics)；(9)、語言支持(languagesupport)；(10)、診斷(diagnostics)；(11)、通用工具(general utilities)。字符串、容器、算法、迭代器四部分采用了模板技術，一般被統稱為STL(Standard Template Library,即標準模板庫)。

???????? 在C++標準中，STL被組織成了13個頭文件：<algorithm>、<deque>、<functional>、<iterator>、<vector>、<list>、<map>、<memory>、<numeric>、<queue>、<set>、<stack>、<utility>。

建議72：熟悉STL中的有關術語

?????????(1)、容器：是一個對象，它將對象作為元素來存儲；(2)、泛型(Genericity)：泛型就是通用，或者說是類型獨立；(3)算法：就是對一個對象序列所采取的某些操作，例如std::sort()、std::copy()、std::remove()；(4)、適配器(Adaptor)：是一個非常特殊的對象，它的作用就是使函數轉化為函數對象，或者是將多參數的函數對象轉化為少參數的函數對象；(5)、O(h)：它是一個表示算法性能的特殊符號，在STL規范中用于表示標準庫算法和容器操作的最低性能極限；(6)、迭代器：是一種可以當做通用指針來使用的對象，迭代器可以用于元素遍歷、元素添加和元素刪除。

建議73：刪除指針的容器時避免資源泄露

?????????STL容器雖然智能，但尚不能擔當刪除它們所包含指針的這一責任。所以，在要刪除指針的容器時須避免資源泄露：或者在容器銷毀前手動刪除容器中的每個指針，或者使用智能引用計數指針對象(比如Boost的shared_ptr)來代替普通指針。

建議74：選擇合適的STL容器

?????????容器分為：(1)、標準STL序列容器：vector、string、deque和list；(2)、標準STL關聯容器：set、multiset、map和multimap；(3)、非標準序列容器：slist(單向鏈表)和rope(重型字符串)；(4)、非標準關聯容器：hash_set、hash_multiset、hash_map和hash_multimap；(5)、標準非STL容器：數組、bitset、valarray、stack、queue和priority_queue。

建議75：不要在STL容器中存儲auto_ptr對象

?????????auto_ptr是C++標準中提供的智能指針，它是一個RAII對象，它在初始化時獲得資源，析構時自動釋放資源。C++標準中規定：STL容器元素必須能夠進行拷貝構造和賦值操作。禁止在STL容器中存儲auto_ptr對象原因有兩個：(1)、auto_ptr拷貝操作不安全，會使原指針對象變NULL；(2)、嚴重影響代碼的可移植性。

建議76：熟悉刪除STL容器中元素的慣用法

?????????(1)、刪除容器中具有特定值的元素：如果容器是vector、string或deque，使用erase-remove的慣用法(remove只會將不應該刪除的元素前移，然后返回一個迭代器，該迭代器指向的是那個應該刪除的元素，所以如果要真正刪除這一元素，在調用remove之后還必須調用erase)；如果容器時list，使用list::remove；如果容器是標準關聯容器，使用它的erase成員函數；(2)、刪除容器中滿足某些條件的所有元素：如果容器是vector、string或deque，使用erase-remove_if慣用法；如果容器是list，使用list::remove_if；如果容器是標準關聯容器，使用remove_copy_if & swap組合算法，或者自己寫一個遍歷刪除算法。

建議77：小心迭代器的失效

???????? 迭代器是一個對象，其內存大小為12(sizeof(vector<int>::iterator)，vs2010,32bit)。引起迭代器失效的最主要操作就是插入、刪除。對于序列容器(如vector和deque)，插入和刪除操作可能會使容器的部分或全部迭代器失效。因為vector和deque必須使用連續分配的內存來存儲元素，向容器中添加一個元素可能會導致后面鄰接的內存沒有可用的空閑空間而引起存儲空間的重新分配。一旦這種情況發生，容器中的所有的迭代器就會全部失效。

建議78：盡量使用vector和string代替動態分配數組

?????????相較于內建數組，vector和string具有幾方面的優點：(1)、它們能夠自動管理內存；(2)、它們提供了豐富的接口；(3)、與C的內存模型兼容；(4)、集眾人智慧之大成。

建議79：掌握vector和string與C語言API的通信方式

?????????使用vector::operator[]和string::c_str是實現STL容器與C語言API通信的最佳方式。

建議80：多用算法調用，少用手寫循環

?????????用算法調用代替手工編寫的循環，具有幾方面的優點：(1)、效率更高；(2)、不易出錯；(3)、可維護性更好。

?

第二部分 編碼習慣和規范篇

?

第8章???讓程序正確執行

建議81：避免無意中的內部數據裸露

???????? 對于const成員函數，不要返回內部數據的句柄，因為它會破壞封裝性，違反抽象性，造成內部數據無意中的裸露，這會出現很多“不可思議”的情形，比如const對象的非常量性。

建議82：積極使用const為函數保駕護航

?????????const的真正威力體現在幾個方面：(1)、修飾函數形式的參數：const只能修飾輸入參數，對于內置數據類型的輸入參數，不要將“值傳遞”的方式改為“const 引用傳遞”；(2)、修飾函數返回值；(3)、修飾成員函數：用const修飾成員函數的目的是提高程序的健壯性。const成員函數不允許對數據成員進行任何修改。

???????? 關于const成員函數，須遵循幾個規則：(1)、const對象只能訪問const成員函數，而非const對象可以訪問任意的成員函數；(2)、const對象的成員是不可修改的，然而const對象通過指針維護的對象卻是可以修改的；(3)、const成員函數不可以修改對象的數據，不管對象是否具有const性質。

建議83：不要返回局部變量的引用

?????????局部變量的引用是一件不太靠譜的事兒，所以盡量避免讓函數返回局部變量的引用。同時也不要返回new生成對象的引用，因為這樣會讓代碼層次混亂，讓使用者苦不堪言。

建議84：切忌過度使用傳引用代替傳對象

?????????相較于傳對象，傳引用的優點：它減少了臨時對象的構造與析構，所以更具效率。但須審慎地使用傳引用替代傳對象，必須傳回內部對象時，就傳對象，勿傳引用。

建議85：了解指針參數傳遞內存中的玄機

?????????用指針參數傳回一塊動態申請的內存，是很常見的一種需求。然而如果不甚小心，就很容易造成嚴重錯誤：程序崩潰+內存泄露，解決之道就是用指針的指針來傳遞，或者換種內存傳遞方式，用返回值來傳遞。

建議86：不要講函數參數作為工作變量

?????????工作變量，就是在函數實現中使用的變量。應該防止將函數參數作為工作變量，而對于那些必須改變的參數，最好先用局部變量代替之，最后再將該局部變量的內容賦給該參數，這樣在一定程度上保護了數據的安全。

建議87：躲過0值比較的層層陷阱

?????????(1)、0在不在該類型數據的取值范圍內？(2)、浮點數不存在絕對0值，所以浮點零值比較需特殊處理；(3)區分比較操作符==與賦值操作符=，切忌混淆。

建議88：不要用reinterpret_cast去迷惑編譯器

?????????reinterpret_cast，簡單地說就是保持二進制位不變，用另一種格式來重新解釋，它就是C/C++中最為暴力的類型轉換，所實現的是一個類型到一個毫不相關、完全不同類型的映射。reiterpret_cast僅僅重新解釋了給出對象的比特模型，它是所有類型轉換中最危險的。盡量避免使用reinterpret_cast，除非是在其他轉換都無效的非常情形下。

建議89：避免對動態對象指針使用static_cast

?????????在類層次結構中，用static_cast完成基類和子類指針(或引用)的下行轉換是不安全的。所以盡量避免對動態對象指針使用static_cast，可以用dynamic_cast來代替，或者優化設計，重構代碼。

建議90：盡量少應用多態性數組

?????????多態性數組一方面會涉及C++時代的基類指針與派生類指針之間的替代問題，同時也會涉及C時代的指針運算，而且常會因為這二者之間的不協調引發隱蔽的Bug。

建議91：不要強制去除變量的const屬性

?????????在C++中，const_cast<T*>(a)一般用于從一個類中去除以下這些屬性：const、volatile和_unaligned.強制去除變量的const屬性雖然可以帶來暫時的便利，但這不僅增加了錯誤修改變量的幾率，而且還可能會引發內存故障。

?

第9章???提高代碼的可讀性

建議92：盡量使代碼版面整潔優雅

?????????(1)、避免代碼過長；(2)、代碼縮進和對齊；(3)、空行分隔段落；(4)、使用空格；(5)、語句行。

建議93：給函數和變量起一個“能說話”的名字

?????????(1)、名稱必須直觀，可望文生義，不必解碼；(2)、長度要符合“min_length && max_information”(最小名長度最大信息量)的原則；(3)、與整體風格保持一致；(4)、變量名稱應該是一個“名詞”，或者是“形容詞+名詞”；而函數名稱應該是“動詞+名詞”的組合；(5)、杜絕僅靠大小寫來區分的名稱標示符；(6)、變量名之前附加前綴用來識別變量類型；(7)、C++類或結構的成員變量附加前綴“m_”；全局變量名稱附加前綴“g_”；(8)、單字符變量只能用作循環變量；(9)、類名采用“C+首字母大寫的單詞”形式來命名。

建議94：合理地添加注釋

?????????(1)、使用統一的注釋方法為每個層次的代碼塊添加注釋；(2)、避免不必要的注釋；(3)、掌握代碼注釋量的一個度；(4)、邊寫代碼加邊注釋；(5)、注釋要簡明而準確；(6)、注意特有標簽的特有作用。

建議95：為源代碼設置一定的目錄結構

?????????如果一個軟件所涉及的文件數目比較多，通常要將其進行劃分，為其設置一定的目錄結構，以便于維護，如include、lib、src、doc、release、debug。

建議96：用有意義的標識代替Magic Numbers

?????????用宏或常量替代信息含量較低的MagicNumbers，絕對是一個好習慣，這樣可提高代碼的可讀性與可維護性。

建議97：避免使用“聰明的技巧”

建議98：運算符重載時堅持其通用的含義

建議99：避免嵌套過深與函數過長

建議100：養成好習慣，從現在做起

?

第10章???讓代碼運行得再快些

建議101：用移位實現乘除法運算

?????????在大部分的C/C++編譯器中，用移位的方法比直接調用乘除法子程序生成代碼的效率要高。只要是乘以或除以一個整數常量，均可用移位的方法得到結果，如a=a*9可以拆分成a=a*(8+1)，即a=a(a<<3)+a。移位只對整數運算起作用。

建議102：優化循環，提高效率

?????????應當將最長的循環放在最內層，最短的循環放在最外層，以減少CPU跨切循環層的次數，提高效率。

建議103：改造switch語句

?????????對于case的值，推薦按照它們發生的相對頻率來排序，把最可能發生的情況放在第一位，最不可能的情況放在最后。

建議104：精簡函數參數

?????????函數在調用時會建立堆棧來存儲所需的參數值，因此函數的調用負擔會隨著參數列表的增長而增加。所以，參數的個數會影響進棧出棧的次數，當參數很多的時候，這樣的操作就會花費很長的時間。因此，精簡函數參數，減少參數個數可以提高函數調用的效率。如果精簡后的參數還是比較多，那么可以把參數列表封裝進一個單獨的類中，并且可以通過引用進行傳遞。

建議105：謹慎使用內嵌匯編

?????????匯編語言與其他高級語言相比，更接近機器語言，效率更高，所以在應用程序中如果碰到那些對時間要求苛刻的部分，可以采用匯編語言來重寫。

建議106：努力減少內存碎片

?????????經常性地動態分配和釋放內存會造成堆碎片，尤其是應用程序分配的是很小的內存塊時。避免堆碎片：(1)、盡可能少地使用動態內存，在大多數情況下，可以使用靜態或自動儲存，或者使用STL容器，減少對動態內存的依賴；(2)、盡量分配和重新分配大塊的內存塊，降低內存碎片發生的幾率。內存碎片會影響程序執行的效率。

建議107：正確地使用內聯函數

?????????內聯(inline)函數既能夠去除函數調用所帶來的效率負擔，又能夠保留一般函數的優點。只有當函數非常短小的時候使用inline才能得到預想中的效果。對于編譯器來說，函數內聯與否取決于以下關鍵性的因素：(1)、函數體的大小；(2)、是否有局部對象被聲明；(3)、函數的復雜性(是否存在函數調用、遞歸等)。

建議108：用初始化取代賦值

?????????以用戶初始化代替賦值，可以使效率得到較大的提升，因為這樣可以避免一次賦值函數operator =的調用。因此，當我們在賦值和初始化之間進行選擇時，初始化應該是首選。需要注意的是，對基本的內置數據類型而言，初始化和賦值之間是沒有差異的，因為內置類型沒有構造和析構過程。

建議109：盡可能地減少臨時對象

?????????臨時對象產生的主要情形及避免方法：(1)、參數：采用傳常量引用或指針取代傳值；(2)、前綴或后綴：優先采用前綴操作；(3)、參數轉換：盡量避免這種轉換；(4)、返回值：遵循single-entry/single-exit原則，避免同一個函數中存在多個return語句。

建議110：最后再去優化代碼

?????????在進行代碼優化之前，需要知道：(1)、算法是否正確；(2)、如何在代碼優化和可讀性之間進行選擇；(3)、該如何優化：代碼分析(profiling)工具；(4)、如何選擇優化方向：先算法，再數據結構，最后才是實現細節。

?

第11章???零碎但重要的其他建議

建議111：采用相對路徑包含頭文件

?????????一個“點”(“.\”)代表的是當前目錄所在的路徑，兩個“點”(“..\”)代表的是相對于當前目錄的上一次目錄路徑。

???????? 當寫#include語句時，推薦使用相對路徑；此外，要注意使用比較通用的正斜線“/”，而不要使用僅在Windows下可用的反斜線“\”。

建議112：讓條件編譯為開發出力

?????????條件編譯中的預處理命令主要包括：#if、#ifndef、#ifdef、#endif和#undef等，它們的主要功能是在程序編譯時進行有選擇性的挑選，注釋掉一些指定的代碼，以達到版本控制、防止對文件重復包含等目的。

建議113：使用.inl文件讓代碼整潔可讀

?????????.inl文件是內聯函數的源文件，.inl文件還可用于模板的定義。.inl文件可以將頭文件與內聯函數的復雜定義隔離開來，使代碼整潔可讀，如果將其用于模板定義，這一優點更加明顯。

建議114：使用斷言來發現軟件問題

?????????斷言assert，只會在調試模式下生成代碼，而在Release版本中則直接無視之。

assert(pData!= NULL && “In Function DataProcess”)assert(0&& “MSG_HANDLE_ERROR”) 建議115：優先選擇編譯和鏈接錯誤

?

?????????靜態檢查：編譯器必須檢查源程序是否符合源語言規定的語法和語義要求，靜態檢查的主要工作就是語義分析，它是獨立于數據和控制流的，可信度相對較高，而且不會增加程序的運行時開銷。

???????? 動態檢查：是在運行時刻對程序的正確性、安全性等做檢查，比如內存不足、溢出、數組越界、除0等，這類檢查對于數據和控制流比較依賴。

???????? C/C++語言屬于一種靜態語言。一個設計較好的C++程序應該是較少地依賴動態檢查，更多地依賴靜態檢查。

建議116：不放過任何一條編譯器警告

?????????強烈建議：(1)、把編譯器的警告級別調至最高；(2)、不要放過編譯器的任何一條警告信息。

建議117：盡量減少文件之間的編譯依賴

?????????不要在頭文件中直接包含要使用的類的頭文件(除了標準庫)，直接包含頭文件這種方式相對簡單方便，但是會耗費大量的編譯時間。推薦使用類的前向聲明來減少文件直接的編譯依賴。用對類聲明的依賴替代對類定義的依賴，這是減少編譯依賴的原則。

???????? 為了加快編譯進程，減少時間的浪費，我們應該盡量減少頭文件依賴，其中的可選方案包括前向聲明、柴郡貓技術等。

建議118：不用在頭文件中使用using

?????????名空間是C++提供的一種機制，可以有效地避免函數名污染。然而在應用時要十分注意：任何情況下都不應在頭文件中使用“using namespace XXX”這樣的語句，而應該在定義時直接用全稱。

建議119：劃分全局名空間避免名污染

?????????使用自己的名空間將全局名空間合理劃分，會有效地減少名污染問題，因為，不要簡單地將所有的符號和名稱統統扔進全局名空間里。

?

第三部分 程序架構和思想篇

?

第12章???面向對象的類設計

建議120：堅持“以行為為中心”的類設計

?????????“以數據為中心”關注類的內部數據結構，習慣將private類型的數據寫在前面，而將public類型的函數寫在后面。

???????? “以行為為中心”關注的重心放在了類的服務和接口上，習慣將public類型的函數寫在前面，而將private類型的數據寫在后面。

建議121：用心做好類設計

?????????在設計一個類時，首先，類的設計就是數據類型的設計，在數據類型的設計中，(1)、類應該如何創建和銷毀呢？這會影響到類的構造函數和析構函數的設計。首先應該確定類是否需要分配資源，如果需要，還要確定這些資源又該如何釋放。(2)、類是否需要一個無參構造函數？如果需要，而恰恰此時這個類已經有了構造函數，那么我們就得顯示地寫一個。(3)、類需要復制構造函數嗎？其參數上加上了const修飾嗎？它是用來定義這個類傳值(pass-by-value)的具體實現的。(4)、所有的數據成員是不是都已經在構造函數中完成了初始化呢？(5)、類需要賦值操作符嗎？賦值操作符能正確地將對象賦給對象本身嗎？它與初始化有什么不同？其參數上加上了const修飾嗎？(6)、類的析構函數需要設置為virtual嗎？(7)、類中哪些值得組合是合法的？合法值的限定條件是什么？在成員函數內部是否對變量值得合法性做了檢查？其次，類的設計是對現實對象進行抽象的一個過程。再次，數據抽象的過程其實是綜合考慮各方面因素進行權衡的一個過程。

建議122：以指針代替嵌入對象或引用

?????????設計類的數據成員時，可以有三種選擇：(1)、嵌入對象；(2)、使用對象引用；(3)、使用對象指針。

???????? 如果在類數據成員中使用到了自定義數據類型，使用指針是一個較為明智的選擇，它有以下幾方面的優點：(1)、成員對象類型的變化不會引起包含類的重編譯；(2)、支持惰性計算，不創建不使用的對象，效率更高；(3)、支持數據成員的多態行為。

建議123：努力將接口最小化且功能完善

?????????類接口的目標是完整且最小。精簡接口函數個數，使每一個函數都具有代表性，并且使其功能恰好覆蓋class的智能，同時又可以獲得接口精簡所帶來的好處：(1)、利于理解、使用，維護成本也相對較低；(2)、可以縮小頭文件長度，并縮短編譯時間。

建議124：讓類的數據隱藏起來

?????????堅持數據封裝，堅持信息隱藏，杜絕公有、保護屬性的存在(數據成員私有、柴郡貓技術)。

建議125：不要讓成員函數破壞類的封裝性

?????????小心類的成員函數返回屬性變量的“直接句柄”，它會破壞辛辛苦苦搭建維護的封裝性，一種方法，將函數的返回值加上const修飾。

建議126：理解“virtual + 訪問限定符”的深層含義

?????????virtual關鍵字是C++中用于實現多態的重要機制，其核心理念就是通過基類訪問派生類定義的函數。

???????? (1)、基類中的一個虛擬私有成員函數，表示實現細節是可以被派生類修改的；(2)、基類中的一個虛擬保護成員函數，表示實現細節是必須被派生類修改的；(3)、基類中的一個虛擬公有成員函數，則表示這是一個接口，不推薦，建議用protected virtual 來替換。

建議127：謹慎恰當地使用友元機制

?????????通常說來，類中的私有成員一般是不允許外面訪問的。但是友元可以超脫這條禁令，它可以訪問該類的私有成員。所帶來的最大好處就是避免了類成員函數的頻繁調用，節約了處理器的開銷，提高了程序的效率。但是，通常，大家認為“友元破壞了類的封裝性”。采用友元機制，一般是基于這樣的需求：一個類的部分成員需要對個別其他類公開。

建議128：控制對象的創建方式

?????????棧和堆是對象的主要分布區，它們對應著兩種基本的對象創建方式：以new方式手動管理的堆創建和只需聲明就可使用的棧創建。

???????? 控制對象的創建方式：(1)、要求在堆中建立對象：為了執行這種限制，必須找到一種方法保證調用new是建立對象的唯一手段。非堆對象是在定義它時自動構造的，而且是在生存期結束時自動釋放的。將析構函數聲明為private，而構造函數保持為public；(2)、禁止在堆中建立對象：要禁止調用new來建立對象，可以通過將operator new函數聲明為private來實現。

建議129：控制實例化對象的個數

?????????當實例化對象唯一時，采用設計模式中的單件模式；當實例化對象為N(N>0)個時，設置計數變量是一個思路。

建議130：區分繼承與組合

?????????(1)、繼承：C++的“繼承”特性可以提高程序的可復用性。繼承規則：若在邏輯上B是一種A，并且A的所有功能和屬性對B而言都有意義，則允許B繼承A的功能和屬性。繼承易于修改或擴展那些被復用的實現。但它的這種“白盒復用”卻容易破壞封裝性，因為這會將父類的實現細節暴露給子類。當父類實現更改時，子類也不得不隨之更改，所以，從父類繼承來的實現將不能在運行期間進行改變；(2)、組合：在邏輯上表示的是“有一個(Hase-A)”的關系，即A是B的一部分。組合屬于“黑盒”復用，被包含對象的內部細節對外是不可見的。所以，它的封裝性相對較好，實現上的相互依賴性比較小。并且可以通過獲取指向其他的具有相同類型的對象引用，在運行期間動態地定義組合。而其缺點就是致使系統中的對象過多。Is-A關系用繼承表達，Has-A關系用組合表達，優先使用(對象)組合。

建議131：不要將對象的繼承關系擴展至對象容器

?????????A是B的基類，B是一種A，但是B的容器卻不能是這種A的容器。

建議132：杜絕不良繼承

?????????在繼承體系中，派生類對象必須是可以取代基類對象的。

建議133：將RAII作為一種習慣

?????????RAII(ResourceAcquisition Is Initialization)，資源獲取即初始化，RAII是C++語言的一種管理資源、避免泄露的慣用方法。RAII的做法是使用一個對象，在其構造時獲取資源，在對象生命周期中控制對象資源的訪問，使之始終保持有效，最后再對象析構時釋放資源。實現這種功能的類即采用了RAII方式，這樣的類被稱為封裝類。

建議134：學習使用設計模式

?????????設計模式是用來“封裝變化、降低耦合”的工具，它是面向對象設計時代的產物，其本質就是充分運用面向對象的三個特性(即：封裝、繼承和多態)，并進行靈活的組合。

建議135：在接口繼承和實現繼承中做謹慎選擇

?????????在接口繼承和實現繼承之間進行選擇時，需要考慮的一個因素就是：基類的默認版本。對于那些無法提供默認版本的函數接口我們選擇函數接口繼承；而對于那些能夠提供默認版本的，函數實現繼承就是最佳選擇。

建議136：遵循類設計的五項基本原則

?????????(1)、單一職責原則(SRP)：一個類，最好只做一件事。SRP可以看作是低耦合、高內聚在面向對象原則上的引申；(2)、開閉原則(OCP)：對擴展開放，對更改關閉，應該能夠不用修改原有類就能擴展一個類的行為；(3)、替換原則(LSP )：子類應當可以替換父類并出現在父類能夠出現的任何地方。反過來則不成立，子類可以替換基類，但是基類不一定能替換子類；(4)、依賴倒置原則(DIP)：高層模塊不依賴于底層模塊，而是二者都依賴于抽象，即抽象不依賴于具體，具體依賴于抽象。依賴一定會存在類與類、模塊與模塊之間。當兩個模塊之間存在緊密的耦合關系時，最好的方法就是分離接口和實現：在依賴之間定義一個抽象的接口使得高層模塊調用接口，底層模塊實現接口的定義，從而有效控制耦合關系，達到依賴于抽象的設計目的；(5)、接口分離原則(ISP)：使用多個小的專門的接口，而不要使用一個大的總接口。接口有效地將細節和抽象隔離開來，體現了對抽象編程的一切好處，接口隔離強調接口的單一性。分離的手段主要有兩種方式：一個是利用委托分離接口，另一個是利用多重繼承分離接口。

?

第13章??返璞歸真的程序設計

建議137：用表驅動取代冗長的邏輯選擇

?????????表驅動法(Table drivenmethod)，是一種不必用很多的邏輯語句(if或case)就可以把表中信息找出來的方法。它是一種設計模式，可用來代替復雜的if/else或switch-case邏輯判斷。

建議138：為應用設定特性集

?????????對待C++高級特性的態度一定要謹慎，是否有必要使用多重繼承、異常、RTTI、模板及模板元編程，一定要做一個審慎的評估，以便為應用選擇合適的特征集，避免使用過分復雜的設計和功能，否則將會使得代碼難于理解和維護。

建議139：編碼之前需三思

?????????在讓電腦運行你的程序之前，先讓你的大腦編譯運行。

建議140：重構代碼

?????????重構無止境，重構你的代碼，精雕細琢，千錘百煉。

建議141：透過表面的語法挖掘背后的語義

建議142：在未來時態下開發C++程序

?????????在未來時態下開發C++程序，需要考慮代碼的可重用性、可維護性、健壯性，以及可移植性。

建議143：根據你的目的決定造不造輪子

?????????在編程語言中這些輪子表現為大量的通用類和庫。在工程實踐中，不要重復造輪子；而在學習研究中，鼓勵重復造輪子。

建議144：謹慎在OO與GP之間選擇

?????????面向對象(OO)和泛型編程(GP)是C++提供給程序員的兩種矛盾的思考模式。OO是我嗎難以割舍的設計原則，世界是對象的，我們面向對象分析、設計、編程；而泛型編程則關注于產生通用的軟件組件，讓這些組件在不同的應用場合都能很容易的重用。

建議145：讓內存管理理念與時俱進

?????????學習STL allocator，更新內存管理理念。

建議146：從大師的代碼中學習編程思想與技藝

?????????閱讀代碼需要方法：剛開始不要糾結于代碼的細節，將關注的重點放在代碼的高層結構上，理解代碼的構建過程；之后，再有重點的深入研究，理解對象的構造，明晰算法的步驟，嘗試著深入理解其中的繁雜細節。

建議147：遵循自然而然的C++風格

建議148：了解C++語言的設計目標與原則

建議149：明確選擇C++的理由

總結

以上是生活随笔為你收集整理的编写高质量代码改善C++程序的150个建议的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。