先把 PPT 放出來，文章以后有空再寫吧。
解釋：integers 固定長(zhǎng)度有什么好處？或者說為什么 <stdint.h> typedefs 沒有解決問題？
1. 格式化輸入輸出 scanf/printf，int64_t 應(yīng)該用什么格式？"%d" 還是 "%ld" 還是 "%lld" ？ int_fast32_t 呢？
C99 為了解決這個(gè)，引入了 inttypes.h 頭文件，其中定義了一堆宏，類似 PRId32, PRId64, PRIdFAST32，代碼寫起來是這樣：
int64_t value = getValue();
printf("value = " PRId64 "\n", value);
2. 在 C++ 里，可以用函數(shù)重載 (overload) 來解決。但是 typedef 并不真正引入新類型（golang 與此不同），你如何知道 int_fast32_t 與 int64_t 是不是同一類型呢？另外還有 size_t/time_t 呢。比如
void foo(uint64_t x)
{}
void foo(size_t x)
{}
在有的系統(tǒng)（64 位 Linux）下會(huì)報(bào)編譯錯(cuò)，因?yàn)?size_t 和 uint64_t 都是 unsigned long 類型，不能重載 foo 兩次。怎么辦？用宏和條件編譯嗎？
另外的例子是 time_t 和 int64_t：
void bar(time_t y)
{}
void bar(int64_t y)
{}
這段代碼有錯(cuò)沒錯(cuò)？取決于 time_t 與 int64_t 是不是同樣的 typedef，如果整數(shù)不定長(zhǎng)，除了用丑陋的 #if / #endif 條件編譯，有辦法解決嗎？
解釋1：finally 有什么用？確實(shí)可以用棧上對(duì)象析構(gòu)函數(shù)里的動(dòng)作來模擬 finally，這又是一個(gè) idiom，為什么不正大光明地讓語言支持這一常用功能呢？
解釋2：數(shù)據(jù)成員的默認(rèn)值有什么用？
如果 class Foo 有一個(gè) enum State state_; 成員，希望初始化為 INVALID_STATE。而 Foo 有 4 個(gè)構(gòu)造函數(shù)，那么你得在每個(gè)構(gòu)造函數(shù)里寫：
Foo::Foo()
: state_(INVALID_STATE)
{}
Foo::Foo(XXXX1)
: state_(INVALID_STATE)
{}
Foo::Foo(XXXX1, YYYY2)
: state_(INVALID_STATE)
{}
Foo::Foo(XXXX1, YYYY2, ZZZZ3)
: state_(INVALID_STATE)
{}
state_ 的初始化要寫四處。對(duì)于 enum，或許還可以用一個(gè)公用的 init() 來初始化。那么對(duì)于 class-type 如 string/vector，用 init() 這種辦法就不能享受 initialization list 的好處了，因?yàn)閷?duì)象在構(gòu)造之后再被賦值，重復(fù)勞動(dòng)。
更糟糕的是，萬一你將來加了一個(gè) int turnedOn_ 成員，初始值為 -1，你得在 4 個(gè)構(gòu)造函數(shù)那里去增加初始化代碼，萬一漏了一處，等待你的就是 uninitialized value，自求多福吧。
關(guān)于 allocator，它沒有帶來任何好處，如果內(nèi)存分配這種事情都需要重新定義，重寫數(shù)據(jù)結(jié)構(gòu)也是理所應(yīng)當(dāng)?shù)模?/p>
http://blog.csdn.net/Solstice/archive/2009/08/02/4401382.aspx
auto_ptr 為什么是壞的，因?yàn)樘菀子缅e(cuò)，且不能放到標(biāo)準(zhǔn)容器里。
Gregory Colvin 最早設(shè)計(jì)的 auto_ptr 是沒有“所有權(quán)轉(zhuǎn)移”這個(gè)語意的，跟現(xiàn)在的 scoped_ptr 一樣。但是標(biāo)準(zhǔn)委員會(huì)莫名其妙地加了這個(gè)語意，造成了很多陷阱。
scoped_ptr/unique_ptr/shared_ptr 都是更好的替代，語意明確，不容易用錯(cuò)。
至于為什么 valarray 是壞的，見《C++ 標(biāo)準(zhǔn)程序庫》相關(guān)章節(jié)，再說，有誰會(huì)用 valarray 做科學(xué)計(jì)算嗎？同樣壞的還有 vector<bool>。
如果 XML/logging 這些基本構(gòu)件不標(biāo)準(zhǔn)化，很難讓幾個(gè)第三方庫協(xié)作起來，因?yàn)槊總€(gè)庫都會(huì)自己發(fā)明一套互不兼容的 logging 和 XML 處理機(jī)制。
如果程序里要把 library A 生成的 XML 對(duì)象傳到 library B 里，恐怕只好用字符串來作為中間媒介，這會(huì)增加很多無謂序列化/反序列化的開銷。
logging 也是如此，如果沒有標(biāo)準(zhǔn)化接口，如何讓 library A 和 library B 按相同的格式寫到同一個(gè)日志文件呢？恐怕又得自己寫寫 adapter 來協(xié)調(diào)這些第三方庫了。
