C++的面向對象設計能力，與java，C#這兩個雜碎相比，一直都是一個大笑話，現在誰敢正兒八經地用c++搞面向對象的框架系統，業界都用java、C#搞設計模式，那關C++什么事情了。而C++也很有自知之明，很知趣，98年之后，就不怎么對外宣稱自己是面向對象的語言，就不怎么搞面向對象研究了（難道是c++下的面向對象已經被研究透徹？），一直在吃template的老本，一直到現在，template這筆豐厚的遺產，貌似還夠c++吃上幾十年。今時今日，virtual早就淪落為template的附庸，除了幫助template搞點類型擦除的行為藝術之外，就很難再見到其身影了。有那么幾年，業界反思c++的面向對象范式，批斗virtual，特別是function出現之后，要搞動態行為，就更加不關virtual的什么事情了。而那幾年，本座也學著大神忌諱virtual關鍵字。現在大家似乎已經達成共識，c++里頭的面向對象能力很不完善，要玩面向對象就應該找其他語言，比如java、C#雜碎；或者更動態類型的語言，好比python，Ruby；或者干脆就是原教旨的面向對象（消息發送），object C，smalltalk。
是啊，1、沒有垃圾回收；2、沒有原生支持的完善反射能力；3、多繼承、虛繼承導致的復雜內存布局。這三座大山面前，c++的碼猿哪敢染指什么面向對象，只在迫不得已的情況下，小心翼翼地使用virtual。但是，事實上，要玩面向對象，c++原來也可以玩得很炫，甚至，可以說，關于面向對象的能力，c++是最強的（沒有之一）。這怎么可能？
所謂的面向對象，說白了，就是對動態行為的信息支持，能在面向對象設計上獨領風騷的語言，都是有著完善的運行時類型信息，就連lisp，其運行時元數據也都很完備。靜態強類型語言（java、C#）與動態語言比，顯然有著強大的靜態類型能力（這不是廢話嗎），能在編譯期就提前發現類型上的諸多錯誤，但是也因此帶上靜態約束，導致呆板、繁瑣的代碼，java的繁文縟節，就是最好證明；而動態語言恰好相反，代碼簡潔，廢話少，但是喪失靜態信息，所謂重構火葬場，那都是血和淚的教訓。靜態語言與動態語言真是一對冤家，如同光的波粒性，己之所長恰是彼之所短，己之所短又是彼之所長，魚與熊掌不可兼得。而C++竟然能集兩家之所長，在靜態語言的領域中玩各種動態行為藝術，比如動態修改類型的反射信息，千奇百怪的花樣作死（喪心病狂的類型轉換）；在動態范疇里面，又可以在編譯期榨取出來靜態類型信息，比如，消息發送的參數信息，想想win32的無類型的wparam和lparam，每次都要猿猴對照手冊解碼，從而最大限度地挖掘編譯器的最大潛力。所以說，c++是最強大的面向對象語言，沒有之一。而把靜態和動態融為一體之后，c++的抽象能力也到達一個全新的高度，自動代碼生成，以后再發揮，這是一個龐大的課題。C++令人發指的強大，絕對遠遠超乎等閑猿猴的想象，特別是那批c with class的草覆蟲原始生物。C++只在部分函數領域的概念上表現令人不滿，比如lambda表達式的參數類型自動推導，monad表達式，缺乏原生的延遲求值等。當然，c++整個的設計理念非常繁雜隨心所欲，但是，卻可以在這一塊混沌里面整理出來一些舉世無雙的思想體系，就是說，c++是一大堆原材料，還有很多廚房用具，包括柴火，讓猿猴自行下廚，做出來的菜肴可以很難吃，也可以是滿漢全席，全看猿猴的手藝。
當然，要在c++里頭搞面向對象，多繼承，虛繼承的那一套，必須徹底拋棄。最大的問題是，多繼承會導致混亂未知的二進制內存布局，虛函數表也一塌糊涂，十幾年前，c++設計新思維的基于policy的范式，雖然令人耳目一新，也因為這種范式下對象的內存布局千奇百怪，所以，即便是最輕微的流行也沒有出現過。當然，也不可能大規模搞消息發送這種很geek的套路，功能太泛化了，其實，消息發送就是動態的給對象添加成員函數，并且可以在運行時知道對象有多少成員函數，那個成員函數可以對該消息做出反應，消息可以是字符串，整型ID（原子）， MFC的消息映射表(BEGIN_MESSAGE_MAP，…)就是一個功能嚴重縮水版的好例子，c++下支持消息映射的庫，絕對可以比破mfc的那一套要好上千百倍，不管是性能、類型安全、使用方便上。目前除了在gui這種變態的場合下才需要大搞消息發送，其他場景，完全可以說用不上，雖然說消息發送很強大很靈活，但也因為其殺傷力太厲害，反而要更加慎重。這好比goto，好比指針，好比stl的迭代器，什么都能做的意思，就是什么都盡量不讓它做。
那么，c++下搞面向對象，還有什么法寶可用呢？當然，在此之前，我們先要直面內存分配。內存既是c++的安身立命之本，又是c++淪落為落水狗喪家犬之幕后大黑手。假如不能為所欲為的操作內存，那么c++的折騰法子，奇技淫巧，起碼要死掉一大半以上。而由于要支持各種花樣作死的內存操作，c++的垃圾回收遲遲未曾出現，就連以巨硬之大能整出來的.net那么好的gc，霸王硬上弓，在給原生c++強硬加上托管功能（垃圾回收），都出力不討好。可見未來垃圾回收，對c++來說，嗯，想想就好了。內存是資源，沒錯，用raii來管理，也無可厚非。但是，內存卻是一種很特殊的資源，1、內存時對象的安身立命之所；2、不同于普通資源，內存很多，不需要馬上用完就急急忙忙啟動清理工作，只要系統還有大把空余的內存，就算還有很多被浪費了的內存，都不要緊，gc也是因為這個原因才得以存在。相比內存，普通資源給人的感覺就是數量及其有限，然后要提交工作結果，否則之前所做努力就廢了。所以，對于內存，應該也要特別對待。就算raii，也要采用專門的raii 。
假設我們的程序里面使用多種內存分配器，比如說，每個線程都有自己專有的內存allocator對象，然后，線程之間的共享數據由全局的內存分配器分配，線程的內部對象都用線程的專屬allocator來分配，那么，內存分配器就是一個線程局部變量（tls，thread local storage）。于是，可以規定，所有的內存分配都通過GetTlsAllocator()來new對象，當然，確定是全局共享變量的話，沒辦法，就只能用GetGlobalAllocator()來new對象。那么，有理由相信，啟動一個任務時，我們先定義一個arena allocator變量，并令其成為當前線程的專屬內存分配器，那么這個任務后面的所有new 出來的對象，包括循環引用，都不必關心。只要任務一結束，這個arena allocator變量一釋放，所有寄生在它身上的對象，全部也都消失得干干凈凈，沒有任何一點點的內存泄露。就算任務內部有大量的內存泄露，那又如何，任務一結束，所有跟此任務有關的一切內存，全部成塊清空。總之，不要以常規raii來解決內存困境，解放思想，在內存釋放上，我們可以有九種辦法讓它死，而不是僅僅靠shared_ptr，unique_ptr，weak_ptr這些狹隘的思維。
其次，完善的面向對象設計，避免不了完備的反射，用以在運行時提供動態類型信息，無參模板函數可以把靜態類型映射成全局唯一變量，好比，TypeOf<vector<int>>，返回vector<int>的全局唯一的const TypeInfo*對象，這個對象包含了vector<int>的所有靜態類型信息，可以這么說，在靜態類型層面上vector<int>所能做的任何事情，比如定義一個vector<int>的變量，也即是創建對象；遍歷、添加元素、析構、復制賦值、元素數量等等一切操作，與vector<int>對應的TypeInfo對象，統統都可以做到。所不同的是，vector<int>的靜態類型代碼，只能用于vector<int>自身的情況（這樣子可放在源文件中），又或者是通過template，表現行為類似于vector<int>的數據類型（代碼必須在頭文件上）。而用TypeInfo*做的事情，全部都在運行時發生，所有的靜態類型信息，全部被帶到運行時來做，所以這些代碼全部都可以處在源文件里面，甚至動態庫里頭，只不過是TypeInfo*操作的對象是一個二進制內存布局和vector<int>一模一樣的內存塊，可以通過強制類型轉換，把運行時的內存塊轉換成靜態編譯時的vector<int>。其實這里的思想，就是想方設法將豐富多彩的靜態類型信息無損的保存到運行時中，讓編譯時能做的事情，運行時也可以做。差別在于，一個是用靜態類型信息來做事情，這里，任何一點點類型上的錯誤，都會讓編譯器很不高興；一個則是用動態類型信息來做事情，這里，顯然只能讓猿猴人肉編譯器。這里，可見動態類型信息和靜態類型信息的表達能力是等價的，也即是同等重要性的意義，而靜態類型信息的意義有多大，相信大家都知道。
那么，如何建立完備的反射信息，這個必須只能用宏來配合完成，外部工具生成的反射信息代碼，功能很不完備，另外，c#、java等的反射信息全部都是編譯器生成的，可定制性很差。我們需要的是一點都不遜色于靜態行為的動態行為。所以，只有由自己自行管理反射，才能做到真正意義上的完備反射。必要時，我們還可以在運行時修改反射信息，從而動態地增刪對象的行為方式，改變對象的面貌。看到這里，是否覺得很多的設計模式，在這里會有更清晰更簡潔的表達方式呢，甚至，輕而易舉就可以出現新的設計模式。比如，以下定義對象反射信息的代碼。
在c++下，由于全局變量生命周期的隨意性（構造函數調用順序不確定，析構順序也不確定），大家都很忌諱其使用，雖然全局變量功能很強大，很多時候都避免不了。但是，標準上還是規定了全局變量的順序，所有的全局變量必須在main函數之前構造完成，其析構函數也只能在main函數結束后才調用。另外，函數的靜態變量必須在其第一次訪問之前構造完整。基于這兩點，我們就可以在main函數之前構建全部的反射信息，流程是這樣子，所有的類型的反射對象都是以函數內部的靜態指針變量存在，他們都通過調用GetStaticAllocator()的內存分配器來創建，這樣子，提供反射信息的函數，就避免了其內部TypeInfo對象的析構發生。最后，main結束后，由GetStaticAllocator()函數內的內存分配器的析構函數統一釋放所有反射信息占用的內存。最后，附上一個例子
struct Student
{
//ClassCat表示為Student的基類，為空類，所以Student可以繼承它，但是代碼上又不需要明確繼承它，非侵入式的基類。
//ClassCat提供二進制序列化操作，xml序列化，json序列化，數據庫序列化等操作
PPInlineClassTI(ClassCat, Student, ti)
{
PPReflAField(ti, name);
PPReflAField(ti, age);
PPReflAField(ti, sex, { kAttrXmlIgnore }); //表示不參與xml的序列化操作
}
AString name;
int age;
bool sex;
};
struct Config : Student
{
PPInlineClassTI(Student, Config, ti)
{
PPReflAField(ti, map);
}
HashMap<U8String, int> map;
};
下期的主角是非侵入式接口，徹底替換c++上的多繼承，功能遠遠好過C#、java雜碎的弱雞接口，更超越狗語言的不知所謂的非侵入式接口。如果僅僅是完備的反射信息，而缺乏非侵入式接口，在c++下搞面向對象，其實還是很痛苦的。但是，有了非侵入式接口之后，一切豁然開朗。甚至可以說，感覺c++里面搞那么多玩意，都不過是為了給非侵入式接口造勢。然而非侵入式接口一直未曾正式誕生過。