C++類庫開發之難，舉世公認，最好的證據就是，1983年到現在，面世幾十年，就沒有一個正兒八經的基礎類庫。是啊，零懲罰，要高性能，要跨平臺，要可擴展，要人性化，又沒有垃圾回收的支持，又沒有運行時類型信息可用，……，這些方方面面的因素糾結在一起，就好像一個巨大的意大利面線團，真的是眾口難調至極。相比C#，java，php等，python等雜碎，它們面世不多久，馬上就有官方的標準庫，你要說這些雜碎的標準庫有多好，那也未必，問題是就有大量人馬心悅誠服高高興興地用之于開發，沒有什么所謂的破心智包袱影響開發效率，甚至有人堅持認為直接用c開發，開發速度都可以快過c++。哪像c++的破事一大坨，總之就是沒有一個好的基礎庫，能夠讓所有的c++開發者大爺滿意。你要說這些c++大爺難侍候，也未必，因為的確就是，不管怎么嘔心瀝血搗鼓出來的庫，確實就是是存在這樣那樣的問題，以至于后面的大量使用中，缺陷擴大越來越明顯，難以忍受。

c++之父一直在重復強調，c++本身美過西施，美得像楊玉環，c++本身沒有問題，只是欠缺好用的基礎庫。問題是好用的基礎庫千喊萬喊，遲遲就是不肯露面。這種情況下，就很讓人懷疑c++的存在意義了。因為很明顯的事實，其他的后生語言早就有龐大嚴謹的標準庫，就你c++諸多借口，搞不出來合格的基礎庫，難道不是c++語言本身就存在重大缺陷，所以才有此困境。很多c++的老殘黨（包括本座），都很贊同c++之父的觀點，c++本身很好，就是欠缺好用的基礎庫。因此大力出奇跡，集整個c++界的精英，花多年的研發，終于奮斗出來stl這個“精品”，另外，還準備了一個候補的boost，以滿足非正常性的需求。

平心而論，stl還是相當不錯的，高性能，可擴展，零懲罰，跨平臺等，基本上都滿足要求了。除了二進制不能共用，除了編譯速度慢，除了代碼膨脹，除了出錯的時候，可能鋪天蓋地的錯誤，這也是沒有辦法的事情，世上哪有十全十美之事?？傊?，在基礎設施嚴重施缺乏的c++上面，能夠做出來這么一個玩意，已經很不容易了。最顯然的事實，面對著stl，除了一小撮亂黨，廣大勞動群眾普遍都認可stl。只是，既然stl是c++里面如此官方的基礎庫，就有必要接受更高標準的考驗。而最終，stl整個的設計，也不可避免地，也絕非完美。這由此可見，c++基礎庫開發的難度。

stl里面的字符串，編碼，iostream，locale，allocator，algorithm里面算法函數的重復（非正交）等的問題，都只是表象。根子上考察，stl的設計思路上犯了左傾和右傾的問題。具體表現如下：
1、對動態類型的畏懼，對靜態類型的過度擁抱。這個問題在c++11之后，有一定程度的改善（出現了shared_ptr, any, variant，內里用到動態類型，起碼有virtual的關鍵字使用）。最明顯的表現就是，把內存分配器allocator做成靜態類型信息，由此造成的麻煩，真是罄竹難書。同一個整型的vector，因為使用不同類型的allocator，也即是，vector<int, xalloc>和vector<int, yalloc>居然分屬不同的類型，然后有一個函數要處理整型數組，要么只能做成模板函數，放在頭文件上，c++原本就編譯速度龜慢，再這樣玩，簡直雪上加霜；如果函數堅持放在cpp文件里面，就只能處理專門的allocator的整型vector。基本上，用stl打造的公共代碼，都要做成頭文件的共享方式，然后每次小小修改，都要引起連鎖的編譯雪崩，大型的c++項目，對于頭文件的修改，考慮到感人的編譯速度，從來都是非到不得已的時候，能不動就不動。豈有此理，天理何在。c++17，標準庫終于接受多態的allocator，這算是對過去左傾激進的糾正。某種程度可以上改善這個問題，因為到時候就可以只專門接受多態的allocator，只可惜，還不完備。

考慮批量分配arena類型的allocator，理想情況下，對于在此arena allocator上分配的對象，假如僅僅涉及到內存問題，其實大多數情況下，析構函數做的就只是釋放內存。那么完全就可以不必苦逼的一個一個調用對象的析構函數，僅僅把arena allocator的內存歸還給系統就好了，這對于運行性能的改善，意義重大，本座測過，真是快了很多。問題是，現有stl的體系下，不能保證容器的元素也使用和容器一樣的allocator，或者說，容器的allocator對象無法傳遞給它的元素，讓容器元素也使用同一個allocator對象來分配內存。比如說，vector<string>，vector和string的allocator都用polymorphic_allocator，但是，vector的allocator對象和string的allocator可能不是同一個。這樣子，我們就不能僅僅簡單的歸還allocator對象內存，而必須像過去那樣子，對vector<string>里面的每一個string都調用析構函數來歸還內存了。差評！所以，一開始，allocator就不應該成為模板參數。另外，stl對allocator的粒度也考慮不周。allocator的迥異應用場合起碼有幾種：1、靜態allocator，專門在main函數運行前的使用，用于生成元數據，這些元數據不必一一析構，主函數結束后，統一一次性釋放；2、全局的allocator，考慮多線程考慮并發；3、scope，可以在一個任務下使用，任務完畢，統一釋放，這里包括函數或者協程；4、gui下的allocator等；只可惜，stl的allocator就只關注全局的allocator。

既然stl對allocator都可以搞成靜態類型的鬼樣子，那么整個stl對運行時類型信息的忽視，逃避，就可想而知了。typeid得到的type_info，除了起到類型的唯一標識符的作用（動態庫下，同一種類型的type_info可能還不一樣），并得到類型的名字之外，就不知道這個type_info還有什么鬼用。即便是這么一點小功能，還是能用于很多地方的，比如，any，variant，雙分派(double dispatch)，由此可見運行時類型信息的重要性。

動態類型信息，也即是反射的重要性，一點都不亞于靜態類型信息。意義重大，有了反射，我們就可以將類型當成變量，到處傳來傳去，也可以保存起來，供后面使用，這里可做的文章，可挖掘的潛力太多了。假如c++的反射信息完善的話，很多頭文件上的模板代碼實現就可以放到源文件里面，模板函數僅僅是提取一下靜態類型的運行時對象，類型擦除，具體實現代碼就可以放到cpp代碼里面去。然后，虛模板函數也可以成為可能了。可以用來創建對象，析構對象，消息發送，非侵入式的接口，序列化……，甚至，連多繼承也都是多余（當然，多繼承還是很有用，只是這貨不應該出現在正式的場合下）。最典型的例子，格式化printf，通過c++11的variadic template，提取類型的運行時類型對象再連同入參的地址，就可以實現現在c庫里面的那個弱雞sprintf，類型安全，緩沖安全，高性能的效果，不但類型可擴展，連同格式化的控制字符都可擴展，甚至還能支持變量名字。stl里面的iostream、locale的設計成這個鬼樣子，也是因為運行時的缺失導致。c++里面要妥當地處理好字符編碼、字符串、文件流、locale這幾者的關系，絕對不是一件容易的事情，所以也難怪stl在這里的一塌糊涂?？催^iostream，locale的實現源碼，大家都說不好，大家都很難受，簡直可以和mfc媲美，這是真的。

c++的反射可以做到零抽象，也即是，只對必要的類型必要的信息做反射，不像java或者C#，不管是什么類型，不管是信息，一些很明顯就是無關緊要的臨時的東西，，不管三七二十一，全部一股腦兒都反射起來。甚至，c++的反射，還能添加用戶自定義的反射信息，甚至，還能運行時修改反射數據。這里，C#、java等，除了attribute或者注解，就別無他法了。反射的意義就在于，它提供了統一的接口，將類型信息全部集中存放在同一個地方，任何關于類型的運行時信息，全部被標準化公理化。有了完善的反射信息，c++里面做一個eval都手到擒來。說白了，反射就是靜態類型語言里把“代碼做成數據”的最重要機制（沒有之一），雖然比之于lisp的“代碼即數據”弱一些，但是已經可以應付99%以上的需求了。甚至可以說，c++的基礎庫遲遲未出現的原因就是因為反射的缺席而導致的（當然，沒有合適的內存管理機制也是重要原因）。而可惜，stl對運行時這一塊的關注，不到%1，這真是令人扼腕嘆息至極。

2，stl的抽象缺陷：臆造抽象，過度抽象，抽象不足，想當然的抽象，大部分的精力都花在刀背上，或者說是很形式化的學術研究。
突然發現文章已經很長了，就先打住，以后有空再好好發揮。對了，cppblog人氣太冷清，門可羅雀。再這樣下去，本座只好轉戰知乎了。