摘要：
並非所有的變化都是進步。隱式轉換所帶來的影響經常是弊大於利。在為自定義型別提供隱式轉換之前，請三思而行，應該依賴的是顯示轉換。
隱式轉換主要有兩個主要的問題：
1.它們會在最意料不到的地方丟擲異常。
2.他們併步總是能與語言的其他元素有效地配合。
隱式轉換建構函式與過載機制配合得很糟糕，而且會使不可見的臨時物件到處出現。在c++中，乙個轉換序列最多只能包含乙個使用者定義的轉換。可是，如果這其中加入了內建轉換，結果就會變得極為混亂。解決方法主要有：
1.預設時，為但引數建構函式加上explicit。
2.使用提供轉換的命名函式代替轉換操作符。
C 程式設計規範之16 避免使用巨集
摘要 巨集是c和c 語言的抽象設施中最生硬的工具，它是披著函式外衣的飢餓的狼，很難馴服，它會我行我素地遊走於各處。要避免使用巨集。這一點在effective c 中也進行了解釋。c 的巨集的主要問題在於，他們表面上看起來很好，而實際上做的卻是另一回事。巨集會忽略作用域，忽略型別系統，忽略所有其他的語...
C 程式設計規範之29 考慮過載，以避免隱式型別轉換
摘要 如無必要勿增物件 因素型別轉換提供了語法上的便利。但是如果建立臨時物件的工作並不不要而且適於優化，那麼可以提供簽名與常見引數型別精確匹配的過載函式，而且不會導致轉換。隱式轉換最常見的例子是字串的比較，見如下程式 class string booloperator const string co...
C 程式設計規範之21 避免跨編譯單元的初始化依賴
摘要 保持順序，不同編譯單元中的名字空間級物件決不應該在初始化上互相依賴，因為其初始化順序是未定義的。這樣做會惹出很多麻煩，輕則在專案中稍做修改就會引發奇怪的崩潰，重則出現嚴重的不可移植問題 即使是同一編譯器的新版本也不行。在不同的編譯單元中定義兩個名字空間級的物件時，先呼叫哪乙個物件的建構函式是沒...