關于對象初始化，c++似乎反復無常，例如：
int x；
在某些語境條件下保證初始化為0，而在另外一些語境下卻并沒有這個保證。而下邊這種情況：
class Point
{
int x,y;
};
Point p;
p的成員函數有的時候被初始化（0），有的時候沒有被初始化。
現在，已經有了一些規則，對象的初始化何時會發生，何時不會發生。但是這些規則過于復雜，對我們的記憶有一定的挑戰，哈哈。
通常如果使用C part of C++而且初始化可能招致運行期成本，那就不保證發生初始化。一旦進入non-C parts of C++,規則有一些變化。這就是為啥array(C part of C++)不保證其內容被初始化，而vector(STL part of C++)卻有此保證。
我們的最佳處理狀態是，在使用任何對象之前先將它初始化。對于無任何成員的內置類型，必須手動完成此事：
int x = 0; //對int進行初始化；
const char *text = " A C-style string"; //對指針進行初始化；
double d;
std::cin >> d; //采用input stream的方式完成初始化；
至于內置類型以外的其他類型，初始化的責任落在了構造函數身上。規則很簡單：確保構造函數都將對象的每一個成員初始化。
這個規則很容易奉行，值得注意的是別混淆了賦值(assignment)和初始化(initialization)。考慮一個表現通訊簿的class：
class PhoneNumber{};
class ABEntry{ //Address Book Entry;
public:
ABEntry(const std::string &name, const std::string &address, const std::list<PhoneNumber> &phones);
private:
std::string theName;
std::string tehAddress;
std::list<PhoneNumber> thePhones;
int numTimesConsulted;
};
ABEntry::ABEntry(const std::string &name, const std::string &address, std::list<PhoneNumber> &phones)
{//以下全是賦值(assignment)，不是初始化(initialization);
theName = name;
theAddress = address;
thePhones = phones;
numTimesConsulted = 0;
}
ABEntry對象會帶給你期望的值，但不是最佳做法。C++規定：對象成員變量的初始化動作發生在進入構造函數本體之前。在ABEntry構造函數內，theName, theAddress, thePhone都不是被初始化，而是被賦值。初始化的時間發生的更早，發生于這些成員函數的default構造函數被自動調用之時(比進入ABEntry構造函數本體的時間更早)。但這對numTimesConsulted不為真，因為他屬于內置類型，不保證在你看到的那個賦值動作的時間點之前獲得初值。
ABEntry構造函數的一個較好寫法是，使用所謂的member initializatin list(成員函數初始列)替換賦值動作：
ABEntry::ABEntry(const std::string &name, const std::string &address,
const std::list<PhoneNumber> &phones)
: theName(name),
theAddress(address),
thePhones(phones),
numTimesConsulted(0)
{}//構造函數本體不需要任何動作
這個構造函數和上一個的結果相同，但是通常效率較高。基于賦值的那個版本首先調用default構造函數為theName, theAddress,和thePhones設立初值，然后立刻再對他們賦值。default的一切作為此刻都浪費了。成員初始列(member initianlization list)的做法避免了這一問題，因為初始列中針對各個變量設的實參，被拿去作為各個成員函數的實參。本例中theName以name為初值進行copy構造，theAddress以address為初值進行copy構造，thePhones以phones為初值進行copy構造。
對于大多數類型而言，比起先調用default構造函數再調用copy assignment操作符，單只調用一次copy構造函數是比較高效的，有事甚至高的多。對于內置類型，如numTimesConsulted，其初始化成本和賦值的成本相同，但為了一致性最好也通過成員初始列來進行初始化。同樣道理，如果我們想default構造一個成員變量，也可以使用成員初始列，只要指定nothing作為初始化列就行了，假設ABEntry有一個無參構造構造函數，我們可以實現如下：
ABEntry::ABEntry()
:theName(), //調用theName的構造函數
theAddress(), //調用theAddress的構造函數
thePhones(), //調用thePhomes的構造函數
numTimesConsulted(0) //記得將此內置類型顯式定義為0
{}
此處記得一條規則，那就是在成員初始列中列出所有的成員變量，以免還得記住哪些成員變量可以無需初值。舉個例子，如numTimesConsulted屬于內置類型，如果(member initialization list)遺漏了他，他就沒有初值，因而可能開啟“不明確行為”的潘多拉盒子。
有些情況下，即使面對的是內置類型，也一定要使用初始列。如果成員變量是const或者reference，他們一定得需要賦初值，而不是賦值。為避免成員變量何時必須在成員初始列中初始化，何時不需要，最簡單的做法就是：總是使用成員初始列。
C++有著十分固定的“成員初始化次序”。是的，次序總是相同的：base classes總是先于derived classes被初始化，而class的成員變量總是以其聲明次序被初始化。讓我們在看一下ABEntry，其theName永遠先被初始化，然后是theAddress，之后thePhones，最后是numTimesConsulted，即使他們在member initialization list中以不同的順序出現，也不會有任何影響。為了避免迷惑，你在member initialization list中條列各個成員時，最好總是以其聲明次序為次序。
一旦我們已經 很小心的將內置型成員變量明確的加以初始化，而且也確保構造函數運用member initialization list初始化base classes和成員變量，那就剩下唯一的一件事情需要操心，就是：不同編譯單元內定義之non-local static對象的初始化次序。
所謂static對象，其壽命從被構造出來直到程序結束為止，因此stack和heap_based對象都被排除。這里所說的static對象包括global對象，定義于namespace對象內的對象，在class內，在函數內，以及在file內被聲明為static的對象。函數內的static對象稱為local static對象，其他則成為non-local static對象，程序結束時static對象會自動銷毀，也就是他們的析構函數會在main()結束時被調用。
所謂編譯單元（translation unit）是指產生單一目標文件（single object file）的那些源碼。基本上是單一源碼文件加上其所包含的頭文件。
現在，上面所涉及到的問題至少包括兩個源碼文件，每一個內含至少一個non-local static對象（也就是說對象是global，或者位于namespace內，或者class內，或者file作用域內被聲明為static）。問題是：如果某個編譯單元內的某個non-local static對象的初始化動作使用了另外一個編譯單元內的non-local static對象，他所使用的這個對象可能沒有初始化，因為C++對“不同編譯單元內的non-local static 對象”的初始化次序并沒有明確定義。
來個例子：
假設有一個FileSystem class，它讓互聯網上的文件看起來像是本機。由于這個class使世界看起來像個單一文件系統，可能會產生一個特殊對象，位于global或namespace作用域內，象征單一文件系統：
class FileSystem{
public:
std::size_t numDisks() const;
};
extern FileSystem tfs;//預備給客戶使用的對象，tfs代表"the file system"
FileSystem對象絕不是一個無關痛癢的對象，因此客戶如果在theFileSystem對象構造完成前就使用他，會得到慘重的代價：
現在假設建立了一個class用以處理文件系統內部的目錄。很自然，他們會用上theFileSystem的對象：
class Directory{
public:
Directory();
};
Directory::Directory()
{
std::size_t disks = tfs.numDisks();
}
進一步假設，這些客戶決定創建一個directory對象，用來放置臨時文件：
Directory tempDir(params);//為臨時文件而做出的目錄
現在，初始化的重要作用顯示出來了，除非tfs在tempDir之前被初始化，否則tempDir的構造函數會用到尚未初始化的tfs。但是tfs和tempDir是不同的人在不同的時間創建出來的，他們是定義于不同編譯單元內地non-local static對象，如何能確認tfs在tempDir之前先被初始化？
哦，這是無法確認的。
一個小小的設計可以改變這種情形：將每一個non-local static 對象搬到自己的專屬函數內（該對象在此函數內被聲明為static）。這些函數返回一個reference用來指向他所包含的對象。然后用戶調用這些函數，而不是直接指涉這些對象。換句話就是non-local static對象被local static對象替換了。這個實現的基礎在于：C++保證，函數內的non-local static 對象會在函數被調用期間首次遇上該對象之定義式時被初始化。所以如果以函數調用替換直接訪問non-local static 對象，就獲得了保證，保證所得的那個reference將指向一個經歷初始化的對象。 此技術實現于上面的代碼如下：
class FileSystem{};//同前
FileSystem &tfs()//這個函數用來替換tfs對象；他在FileSystem中可能是個static。
{
static FileSystem fs;
return fs;
}
class Directory{};
Directory::Directory()
{
std::size_t disks = tfs().numDisks();
}
Directory &tempDir()
{
static Directory td;
return td;
}
修改之后，我們只是使用的是tfs()和tempDir()，而不是tfs和tempDir。也就是使用的是指向static的reference而不是static對象自身。
這樣的reference-returning函數往往十分單純：第一行定義并初始化一個local static對象，第二行返回他。當然，他是絕佳的inline候選，特別是經常被調用的話。但是，另一方面，任何一種non-const static對象，不論是local或者non-local，在多線程下“等待某事發生都會有麻煩的。處理這個麻煩的一種做法是：在程序的單線程啟動階段手工調用所有的reference-returning函數（？？），這可消除與初始化有關的race condition。
為避免對象初始化之前過早的使用他們，你需要做的是三件事：手工初始化內置的non-member對象；使用member initialization list；在初始化次序不確定下加強你的設計。
Things to remember:
1.Manually initialize objects of built-in type, because C++only sometimes initializes them itself;
2.In a constructor, prefer to use the member initialization list to assigenment inside the body of the constructor. List data member in the initialization list in the same order they're declared in the class.
3.Avoid initialization order problems across translation units by replacing non-local static objects with local static objects.
開始寫effective c++的讀書筆記。今天是條款2：盡量以const，enum，inline替換#define(prefer consts,enums,and inlines to #define.)
現在在維護代碼的時候，前輩們大片大片的宏搞得我是那個暈頭轉向啊，真希望他們也看過本條款
。
1.Case：#define ASPECT_RATIO 1.653
Recommendation：const double AspectRatio = 1.653；
Reason: 當使用ASPECT_RATIO但是獲得一個編譯錯誤信息時，可能你會很是發冏，因為這個錯誤信息也許會提到1.653而不是ASPECT_RATIO。如果ASPECT_RATIO定義在非你所寫的頭文件中，你更是因為追蹤他而浪費時間。改為推薦的方式后，你找到的肯定是AspectRatio。當以常量替換#define時，有兩種注意的情況，第一種是定義常量指針（const pointers）。由于常量定義式常放在頭文件內，因此有必要將指針也聲明為const。例如在一個頭文件內定義一個常量的char*-based字符串，必須寫const兩次：
const char* const authorName = "Edmund";
這里采用string對象比其前輩char*-based更合適，
const std::string authorName("Edmund");
第二種是class專屬常量。為了將常量的作用域限制在class內，你必須讓他成為class的一個成員；而為確保此常量只有一個實體，則必須聲明為static：
class GamePlayer{
private:
static const int NumTurns = 5;
int scores[NumTurns];
...
}
然而，你看到的是NumTurns的聲明式而不是定義式，C++通常要求我們所使用的任何東西都要有一個定義式，但如果他是個class的專屬常量而又是static且為整數類型（ints，chars，bools），則做特殊處理。只要不取他們的地址，你可以聲明并使用他們而無需提供定義式。但如果取某個class專屬常量的地址，或縱使不取地址而編譯器卻堅持要看到一個定義式，你就必須提供另外一個定義式：
const int GamePlayer::NumTurns;
由于NumTurns在聲明時已經獲得了初值，因此定義時不可以再設初值。此外，對所謂的“in-class初值設定”也只允許對整數常量進行。如果為非整型則可以采用下面的這種方式：
class CostEstimate{
private:
static const double FudgeFactor;
...
}
const double CostEstimate::FudgeFactor = 1.35;
當你在編譯期需要一個class常量值，例如在上述GamePlayer::scores的數組聲明中，此時如果編譯器不允許“static整數型class常量”完成“in-class初值設定”，可采用enum來解決，其理論基礎是“一個屬于枚舉類型的數值可權充ints被使用”，于是GamePlayer可定義如下：
class GamePlayer{
private:
enum{NumTurns = 5};
int scores[NumTurns];
...
};
注意：取一個const的值是合法的，但是取一個enum的值就是不合法的，取一個#define的值也是不合法的。如果你不想讓別人獲得一個pointer或者reference指向你的某個整數常量，enum可以幫助你實現這個約束。
下邊繼續說預處理器。另外一個常見的#define誤用的情景是以他來實現宏，宏看起來像函數，但是不會招致函數調用帶來的額外開銷，例如：
#define CALL_WITH_MAX(a,b) f((a)>(b)?(a):(b))。他的缺點就不說了，替代方式：
template<class T> inline void callWithMax(const T& a, const T& b)
{
f(a > b?a : b);
}
本條目總結：
1.對于單純常量，最好以const對象或者enums替換#defines；
2.對于形似函數的宏，最好改用inline函數替換#defines。
Ps：本文是第一次在cppblog上發表的文章，呵呵。很早就想在這上面寫點了，但是不是忙這就是忙那，昨天下定決心，先把effective C++(3e)里面的55條讀書筆記寫在這上面。打算每天一個條目，這里面好多跟書上的句子一樣，但是全是我自己敲進去的，不存在任何的paste。所寫均是自己搞清楚的，不明白地方的暫時沒有添加。