我認(rèn)為C++的allocator是依賴注入的一次失敗的嘗試。
C/C++里的內(nèi)存分配和釋放是個重要的事情，我同意，在寫library的時候，除了默認(rèn)使用 malloc/free，還應(yīng)該允許用戶指定使用內(nèi)存分配的函數(shù)。用現(xiàn)在的話說，如果library依賴于內(nèi)存分配與釋放，就應(yīng)該允許用戶注入這種依賴。我看到有些C library是支持這個的，可以在初始化時傳入兩個函數(shù)指針，指向內(nèi)存分配和釋放的函數(shù)。
問題是，allocator是模板參數(shù)，而不是構(gòu)造函數(shù)的參數(shù)。這意味著
1. 由于不能從構(gòu)造函數(shù)傳入allocator，那么每種類型的allocator必須是全局唯一的（Singleton）。無論SGI 的內(nèi)存池（稱為PoolAlloc），還是簡單的new wrapper（稱為NewAlloc）都只從一個地方(region)搞到內(nèi)存，這大大限制了其使用。
2. allocator是vector類型的一部分，vector<string, PoolAlloc> 和 vector<string, NewAlloc> 是兩個類型，不可相互替換。這不僅暴露了實現(xiàn)，還暴露到了類型上，恐怕沒有比這更糟糕的了。
下面舉例說明，
對于1，假設(shè)我有一個任務(wù)（假設(shè)是parse），需要分配很多小塊內(nèi)存，總?cè)萘坎怀^20M。為了防止內(nèi)存泄露及避免內(nèi)存碎片，我希望在任務(wù)開始時，先從系統(tǒng)拿到20M內(nèi)存，供這個任務(wù)使用（parse里分配內(nèi)存只需要改一個指針，釋放內(nèi)存是空操作），等任務(wù)完成后，我一次性釋放這20M內(nèi)存，這樣既高效又安全。然而C++的allocator并不能幫我實現(xiàn)這一點，因為它是全局的。我不能替換全局的 allocator，因為那會影響其他線程。也不能在運行時指定某個vector<string>用哪種allocator，因為類型是編譯時確定的。
對于2，如果我想寫一個普通的以vector<string>為參數(shù)的函數(shù)，這不難
void process(vector<string>& records);
由于vector<string, PoolAlloc>和vector<string, NewAlloc>類型不同，process只能接受一種。
但這完全沒道理，我不過想訪問一個vector<string>，根本不關(guān)心它的內(nèi)存是怎么分配的，卻被什么鬼東西allocator擋在了門外。
我要么提供重載：
void process(vector<string, NewAlloc>& records);
void process(vector<string, PoolAlloc>& records);
要么改寫成模板：
template<typename Alloc>
void process(vector<string, Alloc>& records);
//（同理可知，如果在一個程序里使用多種allocator，那么所有涉及標(biāo)準(zhǔn)庫容器的函數(shù)都必須改寫為函數(shù)模板）
無論哪種"解決辦法"都會導(dǎo)致代碼膨脹，而且給標(biāo)準(zhǔn)庫的使用者帶來完全不必要的負(fù)擔(dān)。
更糟糕的是，allocator給程序庫的作者也帶來了不必要的負(fù)擔(dān)。如果想把process(vector<string>& records)放到某個library中，那么為了適應(yīng)不同的allocator，必須把函數(shù)定義放在頭文件里（因為這是個函數(shù)模板）。明明是針對一個固定類型（vector of string）的函數(shù)，卻不得不寫成函數(shù)模板，把實現(xiàn)細(xì)節(jié)暴露在頭文件里，讓每個用戶都去編譯一遍，這真是完全沒道理。
根據(jù)以上的分析，基本上不可能在一個程序里混用多種allocator，既然一個程序只能有一種allocator，那為什么還要放到每個容器的模板參數(shù)里呢？提供一個全局的鉤子不就行了嘛？
相反，shared_ptr就只有一個模板參數(shù)T，而他同樣可以指定allocator----在構(gòu)造時傳入。
現(xiàn)在看來，vector（以及其他標(biāo)準(zhǔn)庫容器）與其增加一個Alloc模板參數(shù)，不如在構(gòu)造時傳入兩個函數(shù)指針，一個allocate，一個deallocate，定制的效果也一樣。只不過這么做會讓標(biāo)準(zhǔn)委員會的人覺得不夠GP，很可能被拍掉。
總而言之，allocator并不能達(dá)到精確控制（定制）內(nèi)存分配釋放的目的，雖然它名以上是為此而生的。雖然在歷史上可能有過正面效果（封裝 far / near pointer），但現(xiàn)在它無疑就是個累贅。
allocator 就跟 IOStream 的 Locale/Facet，auto_ptr 和 valarray 一樣，成為C++標(biāo)準(zhǔn)一直要背負(fù)的歷史包袱。
有關(guān)問題：
> allocator是個類模板啊... ...其實例化要依賴于容器所關(guān)聯(lián)的數(shù)據(jù)類型啊，怎么從構(gòu)造函數(shù)傳入？
allocator 一開始就不應(yīng)該是個類模板，它只要提供void* alloc(size_t num_bytes) 和 void free(void*) 這兩個功能，就能讓容器正確實現(xiàn)。畢竟在C++里，分配內(nèi)存、構(gòu)造對象、析構(gòu)對象、釋放內(nèi)存這四步是可以獨立開的，allocator 只要管好第1步和第4步就好了。
就算allocator是個未知類型，它也可以從構(gòu)造函數(shù)傳入，而無需作為容器本身的模板參數(shù)。同樣的技術(shù)在shared_ptr里用過，Scott Meyers 也總結(jié)過： http://www.artima.com/cppsource/top_cpp_aha_moments.html （第5條）
> 而且何以有所謂 allocator是singleton...?
每個容器有一個allocator的實例，從這個意義上講，allocator不是Singleton。但是，由于不能從容器的構(gòu)造函數(shù)傳入allocator，那么容器在實例化allocator時只能用默認(rèn)構(gòu)造函數(shù)。這等于是讓容器自己持有的allocator變成一個轉(zhuǎn)發(fā)器，要么轉(zhuǎn)為調(diào)用全局的malloc/free，要么轉(zhuǎn)為調(diào)用某個全局的allocator（比如 SGI 的 內(nèi)存池）。從這個意義上講，每種*類型*的allocator（不是每個allocator實體）只能從一塊地方分配內(nèi)存，所以是個Singleton。
> 如果同一個實例化的容器類的不同對象如果使用不同的allocator，如何保證swap的有效和正確？
shared_ptr是如何做到的？shared_ptr 能從構(gòu)造函數(shù)接受Deleter和Alloctor，而且實現(xiàn)了swap()。
> 但還需探討一下：我們能否改進(jìn)allocator的設(shè)計？究竟這個問題是mission impossible，或者只是Stepanov沒有找到最佳的設(shè)計而已？
很難說。自然，我們可以把allocator變成容器的成員而不是模板類型參數(shù)。
或者干脆把allocator定義成一個abstract base class，然后在容器里放allocator的指針（這么做肯定在標(biāo)準(zhǔn)委員會通不過，那幫人有虛函數(shù)恐懼癥）。但是這樣做了之后，馬上遇到一個問題：allocator的生命期誰來控制，是不是在容器析構(gòu)的時候同時析構(gòu)allocator？如果這樣，一個allocator就只能給一個容器用。如果不析構(gòu)，那么allocator又由誰來釋放呢？
或者按照shared_ptr的做法，allocator是未知類型的，具有值語義，但不必作為容器的模板參數(shù)（allocator實際上是容器的成員，但是其類型及大小未知，所以用了一個trick），這樣生命期的問題倒是解決了。只不過allocator沒辦法內(nèi)聯(lián)，（甚至要通過虛函數(shù)來調(diào)用），很可能會被標(biāo)準(zhǔn)委員會拍死。
另外一個更為重要的問題，allocator沒有傳遞性。比如vector<string> vs，如果 vs 用了我的MyAlloc，我希望它持有的string也用MyAlloc了分配內(nèi)存，這樣我對vs對象涉及的全部內(nèi)存管理都能有所控制。但是很可惜除了自己寫vector，沒辦法把MyAlloc傳遞給vector里的string。（如果把MyAlloc作為string類型的模板參數(shù)，就又回到原來的老路上去了。）