我認(rèn)為C++的allocator是依賴注入的一次失敗的嘗試。

C/C++里的內(nèi)存分配和釋放是個(gè)重要的事情，我同意，在寫library的時(shí)候，除了默認(rèn)使用 malloc/free，還應(yīng)該允許用戶指定使用內(nèi)存分配的函數(shù)。用現(xiàn)在的話說，如果library依賴于內(nèi)存分配與釋放，就應(yīng)該允許用戶注入這種依賴。我看到有些C library是支持這個(gè)的，可以在初始化時(shí)傳入兩個(gè)函數(shù)指針，指向內(nèi)存分配和釋放的函數(shù)。

問題是，allocator是模板參數(shù)，而不是構(gòu)造函數(shù)的參數(shù)。這意味著

1. 由于不能從構(gòu)造函數(shù)傳入allocator，那么每種類型的allocator必須是全局唯一的（Singleton）。無論SGI 的內(nèi)存池（稱為PoolAlloc），還是簡(jiǎn)單的new wrapper（稱為NewAlloc）都只從一個(gè)地方(region)搞到內(nèi)存，這大大限制了其使用。

2. allocator是vector類型的一部分，vector<string, PoolAlloc> 和 vector<string, NewAlloc> 是兩個(gè)類型，不可相互替換。這不僅暴露了實(shí)現(xiàn)，還暴露到了類型上，恐怕沒有比這更糟糕的了。

下面舉例說明，

對(duì)于1，假設(shè)我有一個(gè)任務(wù)（假設(shè)是parse），需要分配很多小塊內(nèi)存，總?cè)萘坎怀^20M。為了防止內(nèi)存泄露及避免內(nèi)存碎片，我希望在任務(wù)開始時(shí)，先從系統(tǒng)拿到20M內(nèi)存，供這個(gè)任務(wù)使用（parse里分配內(nèi)存只需要改一個(gè)指針，釋放內(nèi)存是空操作），等任務(wù)完成后，我一次性釋放這20M內(nèi)存，這樣既高效又安全。然而C++的allocator并不能幫我實(shí)現(xiàn)這一點(diǎn)，因?yàn)樗侨值摹Ｎ也荒芴鎿Q全局的 allocator，因?yàn)槟菚?huì)影響其他線程。也不能在運(yùn)行時(shí)指定某個(gè)vector<string>用哪種allocator，因?yàn)轭愋褪蔷幾g時(shí)確定的。

對(duì)于2，如果我想寫一個(gè)普通的以vector<string>為參數(shù)的函數(shù)，這不難

void process(vector<string>& records);

由于vector<string, PoolAlloc>和vector<string, NewAlloc>類型不同，process只能接受一種。
但這完全沒道理，我不過想訪問一個(gè)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);
//（同理可知，如果在一個(gè)程序里使用多種allocator，那么所有涉及標(biāo)準(zhǔn)庫容器的函數(shù)都必須改寫為函數(shù)模板）


無論哪種"解決辦法"都會(huì)導(dǎo)致代碼膨脹，而且給標(biāo)準(zhǔn)庫的使用者帶來完全不必要的負(fù)擔(dān)。

更糟糕的是，allocator給程序庫的作者也帶來了不必要的負(fù)擔(dān)。如果想把process(vector<string>& records)放到某個(gè)library中，那么為了適應(yīng)不同的allocator，必須把函數(shù)定義放在頭文件里（因?yàn)檫@是個(gè)函數(shù)模板）。明明是針對(duì)一個(gè)固定類型（vector of string）的函數(shù)，卻不得不寫成函數(shù)模板，把實(shí)現(xiàn)細(xì)節(jié)暴露在頭文件里，讓每個(gè)用戶都去編譯一遍，這真是完全沒道理。

根據(jù)以上的分析，基本上不可能在一個(gè)程序里混用多種allocator，既然一個(gè)程序只能有一種allocator，那為什么還要放到每個(gè)容器的模板參數(shù)里呢？提供一個(gè)全局的鉤子不就行了嘛？

相反，shared_ptr就只有一個(gè)模板參數(shù)T，而他同樣可以指定allocator----在構(gòu)造時(shí)傳入。

現(xiàn)在看來，vector（以及其他標(biāo)準(zhǔn)庫容器）與其增加一個(gè)Alloc模板參數(shù)，不如在構(gòu)造時(shí)傳入兩個(gè)函數(shù)指針，一個(gè)allocate，一個(gè)deallocate，定制的效果也一樣。只不過這么做會(huì)讓標(biāo)準(zhǔn)委員會(huì)的人覺得不夠GP，很可能被拍掉。

總而言之，allocator并不能達(dá)到精確控制（定制）內(nèi)存分配釋放的目的，雖然它名以上是為此而生的。雖然在歷史上可能有過正面效果（封裝 far / near pointer），但現(xiàn)在它無疑就是個(gè)累贅。

allocator 就跟 IOStream 的 Locale/Facet，auto_ptr 和 valarray 一樣，成為C++標(biāo)準(zhǔn)一直要背負(fù)的歷史包袱。

有關(guān)問題：

> allocator是個(gè)類模板啊... ...其實(shí)例化要依賴于容器所關(guān)聯(lián)的數(shù)據(jù)類型啊，怎么從構(gòu)造函數(shù)傳入？

allocator 一開始就不應(yīng)該是個(gè)類模板，它只要提供void* alloc(size_t num_bytes) 和 void free(void*) 這兩個(gè)功能，就能讓容器正確實(shí)現(xiàn)。畢竟在C++里，分配內(nèi)存、構(gòu)造對(duì)象、析構(gòu)對(duì)象、釋放內(nèi)存這四步是可以獨(dú)立開的，allocator 只要管好第1步和第4步就好了。

就算allocator是個(gè)未知類型，它也可以從構(gòu)造函數(shù)傳入，而無需作為容器本身的模板參數(shù)。同樣的技術(shù)在shared_ptr里用過，Scott Meyers 也總結(jié)過： http://www.artima.com/cppsource/top_cpp_aha_moments.html （第5條）

> 而且何以有所謂 allocator是singleton...?
每個(gè)容器有一個(gè)allocator的實(shí)例，從這個(gè)意義上講，allocator不是Singleton。但是，由于不能從容器的構(gòu)造函數(shù)傳入allocator，那么容器在實(shí)例化allocator時(shí)只能用默認(rèn)構(gòu)造函數(shù)。這等于是讓容器自己持有的allocator變成一個(gè)轉(zhuǎn)發(fā)器，要么轉(zhuǎn)為調(diào)用全局的malloc/free，要么轉(zhuǎn)為調(diào)用某個(gè)全局的allocator（比如 SGI 的 內(nèi)存池）。從這個(gè)意義上講，每種*類型*的allocator（不是每個(gè)allocator實(shí)體）只能從一塊地方分配內(nèi)存，所以是個(gè)Singleton。

> 如果同一個(gè)實(shí)例化的容器類的不同對(duì)象如果使用不同的allocator，如何保證swap的有效和正確？

shared_ptr是如何做到的？shared_ptr 能從構(gòu)造函數(shù)接受Deleter和Alloctor，而且實(shí)現(xiàn)了swap()。

> 但還需探討一下：我們能否改進(jìn)allocator的設(shè)計(jì)？究竟這個(gè)問題是mission impossible，或者只是Stepanov沒有找到最佳的設(shè)計(jì)而已？

很難說。自然，我們可以把allocator變成容器的成員而不是模板類型參數(shù)。

或者干脆把allocator定義成一個(gè)abstract base class，然后在容器里放allocator的指針（這么做肯定在標(biāo)準(zhǔn)委員會(huì)通不過，那幫人有虛函數(shù)恐懼癥）。但是這樣做了之后，馬上遇到一個(gè)問題：allocator的生命期誰來控制，是不是在容器析構(gòu)的時(shí)候同時(shí)析構(gòu)allocator？如果這樣，一個(gè)allocator就只能給一個(gè)容器用。如果不析構(gòu)，那么allocator又由誰來釋放呢？

或者按照shared_ptr的做法，allocator是未知類型的，具有值語義，但不必作為容器的模板參數(shù)（allocator實(shí)際上是容器的成員，但是其類型及大小未知，所以用了一個(gè)trick），這樣生命期的問題倒是解決了。只不過allocator沒辦法內(nèi)聯(lián)，（甚至要通過虛函數(shù)來調(diào)用），很可能會(huì)被標(biāo)準(zhǔn)委員會(huì)拍死。

另外一個(gè)更為重要的問題，allocator沒有傳遞性。比如vector<string> vs，如果 vs 用了我的MyAlloc，我希望它持有的string也用MyAlloc了分配內(nèi)存，這樣我對(duì)vs對(duì)象涉及的全部?jī)?nèi)存管理都能有所控制。但是很可惜除了自己寫vector，沒辦法把MyAlloc傳遞給vector里的string。（如果把MyAlloc作為string類型的模板參數(shù)，就又回到原來的老路上去了。）