摘要：
如無必要勿增物件：因素型別轉換提供了語法上的便利。但是如果建立臨時物件的工作並不不要而且適於優化，那麼可以提供簽名與常見引數型別精確匹配的過載函式，而且不會導致轉換。
隱式轉換最常見的例子是字串的比較，見如下程式：
class string
;booloperator==(const string&, const string&);
//......**中的某處......
if (something =="hello")
上述**中，編譯器將進行比較操作，但是「==」操作符的兩邊都是conststring，這時就會進行隱式轉換，從char*隱式轉換到string。這樣會對程式的效能造成很大的影響，隱式轉換操作會複製字元，但是我們只是比較，沒有必要複製。
這乙個問題的解決方法是：定義過載以避免轉換。
booloperator==(const string& lhs, const string& rhs);
booloperator==(const string& lhs, const char* rhs);
booloperator==(const char* lhs, const string& rhs);
這樣看起來會有重複**，但是這只是「簽名重複」而已，因為所有三個過載通常都使用相同的後端函式。這樣的簡單過載，使你不可能掉入不成熟的優化的陷阱，而且提供它們只是小菜一碟，尤其是在設計程式庫的時候，這時想要提前**在效能敏感的**中將出現哪些常見型別是很困難的。
C 程式設計規範之16 避免使用巨集
摘要 巨集是c和c 語言的抽象設施中最生硬的工具，它是披著函式外衣的飢餓的狼，很難馴服，它會我行我素地遊走於各處。要避免使用巨集。這一點在effective c 中也進行了解釋。c 的巨集的主要問題在於，他們表面上看起來很好，而實際上做的卻是另一回事。巨集會忽略作用域，忽略型別系統，忽略所有其他的語...
C 程式設計規範之40 要避免提供隱式轉換
摘要 並非所有的變化都是進步。隱式轉換所帶來的影響經常是弊大於利。在為自定義型別提供隱式轉換之前，請三思而行，應該依賴的是顯示轉換。隱式轉換主要有兩個主要的問題 1.它們會在最意料不到的地方丟擲異常。2.他們併步總是能與語言的其他元素有效地配合。隱式轉換建構函式與過載機制配合得很糟糕，而且會使不可見...
C 程式設計規範之21 避免跨編譯單元的初始化依賴
摘要 保持順序，不同編譯單元中的名字空間級物件決不應該在初始化上互相依賴，因為其初始化順序是未定義的。這樣做會惹出很多麻煩，輕則在專案中稍做修改就會引發奇怪的崩潰，重則出現嚴重的不可移植問題 即使是同一編譯器的新版本也不行。在不同的編譯單元中定義兩個名字空間級的物件時，先呼叫哪乙個物件的建構函式是沒...