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