C++霧中風景14:CRTP, 模板的黑魔法-有解無憂

CRTP，奇特的遞回模板模式 (Curiously Recurring Template Pattern) 是 C++ 的一種看起來很怪異的模板編程技巧，
它通過繼承和模板的聯合應用，實作了一種"看似"繼承自己的語法，這種編程的技法，無論是在STL還是Boost之中都被大量使用，像它的名字一樣，看起來很Curiously，筆者在進行資料庫原始碼學習和開發時，發現無論是Clickhouse還是Doris中也同樣大量使用了這種編程技巧來簡化代碼和提高性能，
接下來，用一杯咖啡的時間，來和大家詳細聊聊這種模板的黑魔法，

1.初見

First of All，我們先瞅瞅CRTP長啥樣，

1.1:`std::enable_shared_from_this`類

C++11 引入了一個典型的CRTP的類：std::enable_shared_from_this
當我們有類需要被智能指標share_ptr管理，且需要通過類的成員函式里需要把當前類物件包裝為智能指標傳遞出一個指向自身的share_ptr時，在這種情況下類就需要通過繼承enable_shared_from_this，通過父類的成員函式shared_from_this來獲取指向該類的智能指標，

我們來看看具體的代碼實作邏輯：

struct Good: std::enable_shared_from_this<Good> // 注意：繼承
{
    std::shared_ptr<Good> getptr() {
        return shared_from_this();
    }
};

struct Bad
{
    // 錯誤寫法：用不安全的運算式試圖獲得 this 的 shared_ptr 物件
    std::shared_ptr<Bad> getptr() {
        return std::shared_ptr<Bad>(this);
    }
};

這里我們可以看到，Good類繼承了std::enable_shared_from_this,并且自己是作為模板引數傳遞給父類的，這就給讓代碼看起來有些"唬人"，看起來像是繼承自己一樣，但其實呢？這里只是用到了模板派生，讓父類能夠在編譯器感知到子類的模板存在，二者不是真正意義上的繼承關系，

這里只分析下面兩個問題：

1. 為什么Bad類直接通過this構造shared_ptr會存在問題？
  答：因為原本的this指標就是被shared_ptr管理的，通過getprt函式構造的新的智能指標和和原本管理this指標的的shared_ptr并不互相感知，這會導致指向Bad的this指標被二次釋放！！！
2.為什么通過繼承std::enable_shared_from_this之后就沒有上述問題了？
答：這里截取了部分std::enable_shared_from_this的原始碼并且簡化了一下：

 template<typename _Tp>
    class enable_shared_from_this
    {
    protected:

      enable_shared_from_this(const enable_shared_from_this&) noexcept { }
      ~enable_shared_from_this() { }

    public:
      shared_ptr<_Tp>
      shared_from_this()
      { return shared_ptr<_Tp>(this->_M_weak_this); }

      shared_ptr<const _Tp>
      shared_from_this() const
      { return shared_ptr<const _Tp>(this->_M_weak_this); }

    private:
      mutable weak_ptr<_Tp>  _M_weak_this;
    };

std::enable_shared_from_this的實作由于有些復雜，受限于篇幅，筆者就不展開來分析它具體是怎么樣實作的了，它的能夠規避上述問題的原因如下：

通過自身維護了一個std::weak_ptr讓所有從該物件派生的shared_ptr都通過了std::weak_ptr構造派生，
std::shared_ptr的建構式判斷出物件是std::enable_shared_from_this的之類之后也會同樣通過物件本身的std::weak_ptr構造派生，這個這樣參考計數是互通的，也就不會存在上述double delete的問題了，

enable_shared_from_this的實作邏輯不是本篇的重點，感興趣的朋友可以自行看看STL的原始碼更為徹底的整明白它的實作，

1.2：CRTP的使用

我們重點來看看，這個CRTP在上文的enable_shared_from_this之中起到了怎么樣的作用，從1.1的代碼之中我們可以看到，它核心的作用是利用子類的資訊來生成代碼，我們來具體看看對應的代碼實作

這里通過子類的模板資訊，在父類之中派生出一個指向自身的weak_ptr，

   private:
      mutable weak_ptr<_Tp>  _M_weak_this;

派生出了可以生成子類的函式shared_from_this:

shared_ptr<_Tp>
      shared_from_this()
{ return shared_ptr<_Tp>(this->_M_weak_this); }

通過這兩個核心的派生邏輯，大體上就完成了enable_shared_from_this的骨架構建了，

所以，其實CRTP只不過是表面上看起來有些"唬人"，它的核心作用就是只有一條：是利用子類的資訊來生成代碼，

這種用法很常見，筆者常用的Boost.operators同樣也使用了CRTP，通過繼承其中的boost::less_than_comparable<class>, 可以很輕松的替代std::rel_ops，來代替我們生成比較運算子的代碼，（std::rel_ops這玩意太他喵難用了，我從來都是用boost 替代的，當然，C++20引入了<=>的Spaceship Operator，我們也可以拋棄Boost啦，媽媽再也不用擔心我寫不好多載運算子了～～）

2.How To Use

在上一節之中，我們了解了CRTP的實作，當然這種“奇技淫巧”并不是用來裝逼的，所以本節筆者就結合自己本身的實踐，來描述一下CRTP應該如何在實際的編碼場景之中使用，以及能夠解決一些什么樣的問題，

2.1: 靜態多型

在Clickhouse之中，大量使用了CRTP來實作靜態多型的形式來減少虛函式的調度開銷，

Clickhouse使用了資料庫之中經典的執行模式Volcano model:
資料以一個個tuple形式在運算子之間傳遞，而由于運算子之間不斷互動，導致了大量的虛函式呼叫開銷，影響執行效率，因為虛函式的呼叫需要通過指標查找虛函式表來進行呼叫，同時類的物件因為不需要存盤虛函式指標，也會帶來一部分存盤的開銷，而通過CRTP，恰恰就能通過靜態多型的方式，規避上述問題，

IAggregateFunctionHelper介面
Clickhouse的聚合函式繼承了IAggregateFunctionHelper介面，它就是一個典型的CRTP的使用，利用靜態多型的方式，將虛函式的呼叫轉換為函式指標的呼叫，這個在實際聚合函式的實作程序之中能夠大大提高計算的效率，我們來看看具體的代碼：

template <typename Derived>
class IAggregateFunctionHelper : public IAggregateFunction
{
private:
    static void addFree(const IAggregateFunction * that, AggregateDataPtr place, const IColumn ** columns, size_t row_num, Arena * arena)
    {
        static_cast<const Derived &>(*that).add(place, columns, row_num, arena);
    }

public:
    AddFunc getAddressOfAddFunction() const override { return &addFree; }

我們選取一個聚合函式AggregateFunctionCount來看，它繼承了IAggregateFunctionHelper，而通過getAddressOfAddFunction就可以通過addFree的強制型別轉換，直接獲得子類的函式指標.(這個程序在編譯期間就可以完成，所以稱之為靜態多型，) 通過這種CRTP的巧妙方式降低了上面提到的虛函式開銷，

class AggregateFunctionCount final : public IAggregateFunctionDataHelper<AggregateFunctionCountData, AggregateFunctionCount>
{
public:
    AggregateFunctionCount(const DataTypes & argument_types_) : IAggregateFunctionDataHelper(argument_types_, {}) {}

    void add(AggregateDataPtr place, const IColumn **, size_t, Arena *) const override
    {
        ++data(place).count;
    }

在Clickhouse的代碼注釋之中提到，通過CRTP的方式，能夠有12%的性能提升，可見這種靜態多型的方式對于OLAP的系統的性能的確是有顯著的提升的，

** The inner loop that uses the function pointer is better than using the virtual function.
 * The reason is that in the case of virtual functions GCC 5.1.2 generates code,
 *  which, at each iteration of the loop, reloads the function address (the offset value in the virtual function table) from memory to the register.
 * This gives a performance drop on simple queries around 12%.
 * After the appearance of better compilers, the code can be removed.

2.2: 顛倒繼承

說完了Clickhouse，當然得提一嘴自家的Doris，Doris之中應用了CRTP來實作顛倒繼承的目的，

顛倒繼承(Upside Down Inheritance)，顧名思義就是通過父類向子類添加功能，因為它的效果與普通繼承父到子的邏輯是相反的，第一節的enable_shared_from_this就是利用了顛倒繼承來實作所需要的功能的，接下來，我們來看看Doris的代碼吧：

InternalQueueBase類
Doris實作了一個執行緒安全的Queue結構，它的內部實作了一個Node類，它的next與prev函式就是利用了顛倒繼承與reinterpret_cast<T*>的強制型別轉換，讓父類獲取了能夠回傳子類指標的能力，從而讓子類再通過繼承擁有了對應的能力，

template <typename LockType, typename T>
class InternalQueueBase {
 public:
  struct Node {
   public:
    Node() : parent_queue(NULL), next_node(NULL), prev_node(NULL) {}
    virtual ~Node() {}

    /// Returns the Next/Prev node or NULL if this is the end/front.
    T* next() const {
      boost::lock_guard<LockType> lock(parent_queue->lock_);
      return reinterpret_cast<T*>(next_node);
    }
    T* prev() const {
      boost::lock_guard<LockType> lock(parent_queue->lock_);
      return reinterpret_cast<T*>(prev_node);
    }

   private:
    friend class InternalQueueBase<LockType, T>;

    Node* next_node;
    Node* prev_node;
  };

這里Block類通過CRTP的方式繼承了InternalQueue<Block>::Node，便自動擁有了成為Queue中節點的能力，能夠成為執行緒安全的Queue的元素了，而Block類的next與prev 方法便自動能夠回傳指向Block的指標了，

 class Block : public InternalQueue<Block>::Node {
    public:
        // A null dtor to pass codestyle check
        ~Block() {}

通過CRTP實作顛倒繼承的方式，能夠大大減少我們需要額外撰寫的代碼量，簡化我們的代碼結構和減少coding作業，但是帶來的缺點也很明顯，這種通過模板派生的形式生成的代碼與宏定義一般，相對來說難以理解，不易除錯，所以，舍得之間，大家需要自己選擇，

3.小結

看到這里，想必大家手里的咖啡也喝完了哈，本篇介紹了一個模板使用的黑魔法：CRTP，它在高性能資料庫，金融系統領域作為一種編程技法被大量使用，但是由于其怪異的語法，坦率來說對初學者并不友好，
管中窺豹，我們可以通過CRTP看到C++模板的強大魅力，無論是在代碼簡化，性能提升方面都值得我們繼續深入思考學習，也歡迎大家多多討論，指教，

4.參考資料

維基百科:CRTP
ClickHouse原始碼
Doris原始碼

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/1833.html

標籤：C++

上一篇：typecho文章轉hexo

下一篇：Spring Cloud微服務Sentinel+Apollo限流、熔斷實戰總結

C++霧中風景14:CRTP, 模板的黑魔法