C++類庫開發(fā)之難，舉世公認(rèn)，最好的證據(jù)就是，1983年到現(xiàn)在，面世幾十年，就沒有一個(gè)正兒八經(jīng)的基礎(chǔ)類庫。是啊，零懲罰，要高性能，要跨平臺(tái)，要可擴(kuò)展，要人性化，又沒有垃圾回收的支持，又沒有運(yùn)行時(shí)類型信息可用，……，這些方方面面的因素糾結(jié)在一起，就好像一個(gè)巨大的意大利面線團(tuán)，真的是眾口難調(diào)至極。相比C#，java，php等，python等雜碎，它們面世不多久，馬上就有官方的標(biāo)準(zhǔn)庫，你要說這些雜碎的標(biāo)準(zhǔn)庫有多好，那也未必，問題是就有大量人馬心悅誠服高高興興地用之于開發(fā)，沒有什么所謂的破心智包袱影響開發(fā)效率，甚至有人堅(jiān)持認(rèn)為直接用c開發(fā)，開發(fā)速度都可以快過c++。哪像c++的破事一大坨，總之就是沒有一個(gè)好的基礎(chǔ)庫，能夠讓所有的c++開發(fā)者大爺滿意。你要說這些c++大爺難侍候，也未必，因?yàn)榈拇_就是，不管怎么嘔心瀝血搗鼓出來的庫，確實(shí)就是是存在這樣那樣的問題，以至于后面的大量使用中，缺陷擴(kuò)大越來越明顯，難以忍受。
c++之父一直在重復(fù)強(qiáng)調(diào)，c++本身美過西施，美得像楊玉環(huán)，c++本身沒有問題，只是欠缺好用的基礎(chǔ)庫。問題是好用的基礎(chǔ)庫千喊萬喊，遲遲就是不肯露面。這種情況下，就很讓人懷疑c++的存在意義了。因?yàn)楹苊黠@的事實(shí)，其他的后生語言早就有龐大嚴(yán)謹(jǐn)?shù)臉?biāo)準(zhǔn)庫，就你c++諸多借口，搞不出來合格的基礎(chǔ)庫，難道不是c++語言本身就存在重大缺陷，所以才有此困境。很多c++的老殘黨（包括本座），都很贊同c++之父的觀點(diǎn)，c++本身很好，就是欠缺好用的基礎(chǔ)庫。因此大力出奇跡，集整個(gè)c++界的精英，花多年的研發(fā)，終于奮斗出來stl這個(gè)“精品”，另外，還準(zhǔn)備了一個(gè)候補(bǔ)的boost，以滿足非正常性的需求。
平心而論，stl還是相當(dāng)不錯(cuò)的，高性能，可擴(kuò)展，零懲罰，跨平臺(tái)等，基本上都滿足要求了。除了二進(jìn)制不能共用，除了編譯速度慢，除了代碼膨脹，除了出錯(cuò)的時(shí)候，可能鋪天蓋地的錯(cuò)誤，這也是沒有辦法的事情，世上哪有十全十美之事。總之，在基礎(chǔ)設(shè)施嚴(yán)重施缺乏的c++上面，能夠做出來這么一個(gè)玩意，已經(jīng)很不容易了。最顯然的事實(shí)，面對(duì)著stl，除了一小撮亂黨，廣大勞動(dòng)群眾普遍都認(rèn)可stl。只是，既然stl是c++里面如此官方的基礎(chǔ)庫，就有必要接受更高標(biāo)準(zhǔn)的考驗(yàn)。而最終，stl整個(gè)的設(shè)計(jì)，也不可避免地，也絕非完美。這由此可見，c++基礎(chǔ)庫開發(fā)的難度。
stl里面的字符串，編碼，iostream，locale，allocator，algorithm里面算法函數(shù)的重復(fù)（非正交）等的問題，都只是表象。根子上考察，stl的設(shè)計(jì)思路上犯了左傾和右傾的問題。具體表現(xiàn)如下：
1、對(duì)動(dòng)態(tài)類型的畏懼，對(duì)靜態(tài)類型的過度擁抱。這個(gè)問題在c++11之后，有一定程度的改善（出現(xiàn)了shared_ptr, any, variant，內(nèi)里用到動(dòng)態(tài)類型，起碼有virtual的關(guān)鍵字使用）。最明顯的表現(xiàn)就是，把內(nèi)存分配器allocator做成靜態(tài)類型信息，由此造成的麻煩，真是罄竹難書。同一個(gè)整型的vector，因?yàn)槭褂貌煌愋偷腶llocator，也即是，vector<int, xalloc>和vector<int, yalloc>居然分屬不同的類型，然后有一個(gè)函數(shù)要處理整型數(shù)組，要么只能做成模板函數(shù)，放在頭文件上，c++原本就編譯速度龜慢，再這樣玩，簡直雪上加霜；如果函數(shù)堅(jiān)持放在cpp文件里面，就只能處理專門的allocator的整型vector。基本上，用stl打造的公共代碼，都要做成頭文件的共享方式，然后每次小小修改，都要引起連鎖的編譯雪崩，大型的c++項(xiàng)目，對(duì)于頭文件的修改，考慮到感人的編譯速度，從來都是非到不得已的時(shí)候，能不動(dòng)就不動(dòng)。豈有此理，天理何在。c++17，標(biāo)準(zhǔn)庫終于接受多態(tài)的allocator，這算是對(duì)過去左傾激進(jìn)的糾正。某種程度可以上改善這個(gè)問題，因?yàn)榈綍r(shí)候就可以只專門接受多態(tài)的allocator，只可惜，還不完備。
考慮批量分配arena類型的allocator，理想情況下，對(duì)于在此arena allocator上分配的對(duì)象，假如僅僅涉及到內(nèi)存問題，其實(shí)大多數(shù)情況下，析構(gòu)函數(shù)做的就只是釋放內(nèi)存。那么完全就可以不必苦逼的一個(gè)一個(gè)調(diào)用對(duì)象的析構(gòu)函數(shù)，僅僅把a(bǔ)rena allocator的內(nèi)存歸還給系統(tǒng)就好了，這對(duì)于運(yùn)行性能的改善，意義重大，本座測(cè)過，真是快了很多。問題是，現(xiàn)有stl的體系下，不能保證容器的元素也使用和容器一樣的allocator，或者說，容器的allocator對(duì)象無法傳遞給它的元素，讓容器元素也使用同一個(gè)allocator對(duì)象來分配內(nèi)存。比如說，vector<string>，vector和string的allocator都用polymorphic_allocator，但是，vector的allocator對(duì)象和string的allocator可能不是同一個(gè)。這樣子，我們就不能僅僅簡單的歸還allocator對(duì)象內(nèi)存，而必須像過去那樣子，對(duì)vector<string>里面的每一個(gè)string都調(diào)用析構(gòu)函數(shù)來歸還內(nèi)存了。差評(píng)！所以，一開始，allocator就不應(yīng)該成為模板參數(shù)。另外，stl對(duì)allocator的粒度也考慮不周。allocator的迥異應(yīng)用場(chǎng)合起碼有幾種：1、靜態(tài)allocator，專門在main函數(shù)運(yùn)行前的使用，用于生成元數(shù)據(jù)，這些元數(shù)據(jù)不必一一析構(gòu)，主函數(shù)結(jié)束后，統(tǒng)一一次性釋放；2、全局的allocator，考慮多線程考慮并發(fā)；3、scope，可以在一個(gè)任務(wù)下使用，任務(wù)完畢，統(tǒng)一釋放，這里包括函數(shù)或者協(xié)程；4、gui下的allocator等；只可惜，stl的allocator就只關(guān)注全局的allocator。
既然stl對(duì)allocator都可以搞成靜態(tài)類型的鬼樣子，那么整個(gè)stl對(duì)運(yùn)行時(shí)類型信息的忽視，逃避，就可想而知了。typeid得到的type_info，除了起到類型的唯一標(biāo)識(shí)符的作用（動(dòng)態(tài)庫下，同一種類型的type_info可能還不一樣），并得到類型的名字之外，就不知道這個(gè)type_info還有什么鬼用。即便是這么一點(diǎn)小功能，還是能用于很多地方的，比如，any，variant，雙分派(double dispatch)，由此可見運(yùn)行時(shí)類型信息的重要性。
動(dòng)態(tài)類型信息，也即是反射的重要性，一點(diǎn)都不亞于靜態(tài)類型信息。意義重大，有了反射，我們就可以將類型當(dāng)成變量，到處傳來傳去，也可以保存起來，供后面使用，這里可做的文章，可挖掘的潛力太多了。假如c++的反射信息完善的話，很多頭文件上的模板代碼實(shí)現(xiàn)就可以放到源文件里面，模板函數(shù)僅僅是提取一下靜態(tài)類型的運(yùn)行時(shí)對(duì)象，類型擦除，具體實(shí)現(xiàn)代碼就可以放到cpp代碼里面去。然后，虛模板函數(shù)也可以成為可能了。可以用來創(chuàng)建對(duì)象，析構(gòu)對(duì)象，消息發(fā)送，非侵入式的接口，序列化……，甚至，連多繼承也都是多余（當(dāng)然，多繼承還是很有用，只是這貨不應(yīng)該出現(xiàn)在正式的場(chǎng)合下）。最典型的例子，格式化printf，通過c++11的variadic template，提取類型的運(yùn)行時(shí)類型對(duì)象再連同入?yún)⒌牡刂罚涂梢詫?shí)現(xiàn)現(xiàn)在c庫里面的那個(gè)弱雞sprintf，類型安全，緩沖安全，高性能的效果，不但類型可擴(kuò)展，連同格式化的控制字符都可擴(kuò)展，甚至還能支持變量名字。stl里面的iostream、locale的設(shè)計(jì)成這個(gè)鬼樣子，也是因?yàn)檫\(yùn)行時(shí)的缺失導(dǎo)致。c++里面要妥當(dāng)?shù)靥幚砗米址幋a、字符串、文件流、locale這幾者的關(guān)系，絕對(duì)不是一件容易的事情，所以也難怪stl在這里的一塌糊涂。看過iostream，locale的實(shí)現(xiàn)源碼，大家都說不好，大家都很難受，簡直可以和mfc媲美，這是真的。
c++的反射可以做到零抽象，也即是，只對(duì)必要的類型必要的信息做反射，不像java或者C#，不管是什么類型，不管是信息，一些很明顯就是無關(guān)緊要的臨時(shí)的東西，，不管三七二十一，全部一股腦兒都反射起來。甚至，c++的反射，還能添加用戶自定義的反射信息，甚至，還能運(yùn)行時(shí)修改反射數(shù)據(jù)。這里，C#、java等，除了attribute或者注解，就別無他法了。反射的意義就在于，它提供了統(tǒng)一的接口，將類型信息全部集中存放在同一個(gè)地方，任何關(guān)于類型的運(yùn)行時(shí)信息，全部被標(biāo)準(zhǔn)化公理化。有了完善的反射信息，c++里面做一個(gè)eval都手到擒來。說白了，反射就是靜態(tài)類型語言里把“代碼做成數(shù)據(jù)”的最重要機(jī)制（沒有之一），雖然比之于lisp的“代碼即數(shù)據(jù)”弱一些，但是已經(jīng)可以應(yīng)付99%以上的需求了。甚至可以說，c++的基礎(chǔ)庫遲遲未出現(xiàn)的原因就是因?yàn)榉瓷涞娜毕鴮?dǎo)致的（當(dāng)然，沒有合適的內(nèi)存管理機(jī)制也是重要原因）。而可惜，stl對(duì)運(yùn)行時(shí)這一塊的關(guān)注，不到%1，這真是令人扼腕嘆息至極。
2，stl的抽象缺陷：臆造抽象，過度抽象，抽象不足，想當(dāng)然的抽象，大部分的精力都花在刀背上，或者說是很形式化的學(xué)術(shù)研究。
突然發(fā)現(xiàn)文章已經(jīng)很長了，就先打住，以后有空再好好發(fā)揮。對(duì)了，cppblog人氣太冷清，門可羅雀。再這樣下去，本座只好轉(zhuǎn)戰(zhàn)知乎了。