這里假設(shè) vector 的運(yùn)算定義為對(duì)操作數(shù) vector 中相同位置的元素進(jìn)行運(yùn)算，最后得到一個(gè)新的 vector。具體來(lái)說(shuō)就是，假如 vector<int> d1{1, 2, 3}, d2{4, 5, 6};則， v1 + v2 等于 {5, 7, 9}。實(shí)現(xiàn)這樣的運(yùn)算看起來(lái)并不是很難，一個(gè)非常直觀的做法如下所示：

vector<int> operator+(const vector<int>& v1, const vector<int>& v2) {
  // 假設(shè) v1.size() == v2.size()
  vector<int> r;

  r.reserve(v1.size());
  for (auto i = 0; i < v1.size(); ++i) {
    r.push_back(v1[i] + v2[i]);
  }
  return r;
}

// 同理，需要重載其它運(yùn)算符
我們針對(duì) vector 重載了每種運(yùn)算符，這樣一來(lái)，vector 的運(yùn)算就與一般簡(jiǎn)單類型無(wú)異，實(shí)現(xiàn)也很直白明了，但顯然這個(gè)直白的做法有一個(gè)嚴(yán)重的問題：效率不高。效率不高的原因在于整個(gè)運(yùn)算過(guò)程中，每一步的運(yùn)算都產(chǎn)生了中間結(jié)果，而中間結(jié)果是個(gè) vector，因此每次都要分配內(nèi)存，如果參與運(yùn)算的 vector 比較大，然后運(yùn)算又比較長(zhǎng)的話，效率會(huì)比較低，有沒有更好的做法呢？

既然每次運(yùn)算產(chǎn)生中間結(jié)果會(huì)導(dǎo)致效率問題，那能不能優(yōu)化掉中間結(jié)果？回過(guò)頭來(lái)看，這種 vector 的加減乘除與普通四則運(yùn)算并無(wú)太大差異，在編譯原理中，對(duì)這類表達(dá)式進(jìn)行求值通?？梢酝ㄟ^(guò)先把表達(dá)式轉(zhuǎn)為一棵樹，然后通過(guò)遍歷這棵樹來(lái)得到最后的結(jié)果，結(jié)果的計(jì)算是一次性完成的，并不需要保存中間狀態(tài)，比如對(duì)于表達(dá)式：v1 + v2 * v3，我們通?？梢韵葘⑵滢D(zhuǎn)化為如下樣子的樹：

因此求值就變成一次簡(jiǎn)單的中序遍歷，那么我們的 vector 運(yùn)算是否也可以這樣做呢？

表達(dá)式模板

要把中間結(jié)果去掉，關(guān)鍵是要推遲對(duì)表達(dá)式的求值，但 c++ 不支持 lazy evaluation，因此需要想辦法把表達(dá)式的這些中間步驟以及狀態(tài)，用一個(gè)輕量的對(duì)象保存起來(lái)，具體來(lái)說(shuō)，就是需要能夠?qū)⒈磉_(dá)式的中間步驟的操作數(shù)以及操作類型封裝起來(lái)，以便在需要時(shí)能動(dòng)態(tài)的執(zhí)行這些運(yùn)算得到結(jié)果，為此需要定義類似如下這樣一個(gè)類：

enum OpType {
  OT_ADD,
  OT_SUB,
  OT_MUL,
  OT_DIV,
};

class VecTmp {
  int type_;
  const vector<int>& op1_;
  const vector<int>& op2_;

public:
  VecTmp(int type, const vector<int>& op1, const vector<int>& op2)
    : type_(type), op1_(op1), op2_(op2) {}

  int operator[](const int i) const {
    switch(type_) {
      case OT_ADD: return op1_[i] + op2_[i];
      case OT_SUB: return op1_[i] - op2_[i];
      case OT_MUL: return op1_[i] * op2_[i];
      case OT_DIV: return op1_[i] / op2_[i];
      default: throw "bad type";
    }
  }
};

有了這個(gè)類，我們就可以把一個(gè)簡(jiǎn)單的運(yùn)算表達(dá)式的結(jié)果封裝到一個(gè)對(duì)象里面去了，當(dāng)然，我們得先將加法操作符(以及其它操作符)重載一下：

VecTmp operator+(const vector<int>& op1, const vector<int>& op2) {
  return VecTmp(OT_ADD, op1, op2);
}

這樣一來(lái)，對(duì)于 v1 + v2，我們就得到了一個(gè)非常輕量的 VecTmp 對(duì)象，而該對(duì)象可以很輕松地轉(zhuǎn)化 v1 + v2 的結(jié)果(遍歷一遍 VecTmp 中的操作數(shù))。但上面的做法還不能處理 v1 + v2 * v3 這樣的套嵌的復(fù)雜表達(dá)式：v2 * v3 得到一個(gè) VecTmp，那 v1 + VecTmp 怎么搞呢？

同理，我們還是得把 v1 + VecTmp 放到一個(gè)輕量的對(duì)象里，因此最好我們的 VecTmp 中保存的操作數(shù)也能是 VecTmp 類型的，有點(diǎn)遞歸的味道。。。用模板就可以了，于是得到如下代碼：

#include <vector>
#include <iostream>

using namespace std;

enum OpType {
  OT_ADD,
  OT_SUB,
  OT_MUL,
  OT_DIV,
};

template<class T1, class T2>
class VecSum {
    OpType type_;
  const T1& op1_;
  const T2& op2_;
 public:
  VecSum(int type, const T1& op1, const T2& op2): type_(type), op1_(op1), op2_(op2) {}
 
    int operator[](const int i) const {
      switch(type_) {
        case OT_ADD: return op1_[i] + op2_[i];
        case OT_SUB: return op1_[i] - op2_[i];
        case OT_MUL: return op1_[i] * op2_[i];
        case OT_DIV: return op1_[i] / op2_[i];
        default: throw "bad type";
      }
    }
};

template<class T1, class T2>
VecSum<T1, T2> operator+(const T1& t1, const T2& t2) {
  return VecSum<T1, T2>(OT_ADD, t1, t2);
}

template<class T1, class T2>
VecSum<T1, T2> operator*(const T1& t1, const T2& t2) {
  return VecSum<T1, T2>(OT_MUL, t1, t2);
}

int main() {
  std::vector<int> v1{1, 2, 3}, v2{4, 5, 6}, v3{7, 8, 9};
  auto r = v1 + v2 * v3;
  for (auto i = 0; i < r.size(); ++i) {
    std::cout << r[i] << " ";
  }
}

上面的代碼漂亮地解決了前面提到的效率問題，擴(kuò)展性也很好而且對(duì) vector 來(lái)說(shuō)還是非侵入性的，雖然實(shí)現(xiàn)上乍看起來(lái)可能不是很直觀，除此也還有些小問題可以更完善些：

操作符重載那里很可能會(huì)影響別的類型，因此最好限制一下，只針對(duì) vector 和 VecTmp 進(jìn)行重載，這里可以用 SFINAE 來(lái)處理。

VecTmp 的 operator[] 函數(shù)中的 switch 可以優(yōu)化掉，VecTmp 模板只需增加一個(gè)參數(shù)，然后對(duì)各種運(yùn)算類型進(jìn)行偏特化就可以了。

VecTmp 對(duì)保存的操作數(shù)是有要求的，只能是 vector 或者是 VecTmp<>，這里也應(yīng)該用 SFINAE 強(qiáng)化一下限制，使得用錯(cuò)時(shí)出錯(cuò)信息好看些。

現(xiàn)在我們來(lái)重頭再看看這一小段奇怪的代碼，顯然關(guān)鍵在于 VecTmp 這個(gè)類，我們可以發(fā)現(xiàn)，它的接口其實(shí)很簡(jiǎn)單直白，但它的類型卻可以是那么地復(fù)雜，比如說(shuō)對(duì)于 v1 + v2 * v3 這個(gè)表達(dá)式，它的結(jié)果的類型是這樣的： VecTmp<vector<int>, VecTmp<vector<int>, vector<int>>>，如果表達(dá)式再?gòu)?fù)雜些，它的類型也就更復(fù)雜了，如果你看仔細(xì)點(diǎn)，是不是還發(fā)現(xiàn)這東西和哪里很像？像一棵樹，一棵類型的樹。

這棵樹看起來(lái)是不是還很眼熟，每個(gè)葉子結(jié)點(diǎn)都是 vector，而每個(gè)內(nèi)部結(jié)點(diǎn)則是由 VecTmp 實(shí)例化的：這是一棵類型的樹，在編譯時(shí)就確定了。這種通過(guò)表達(dá)式在編譯時(shí)得到的復(fù)雜類型有一個(gè)學(xué)名叫： Expression template。在 c++ 中每一個(gè)表達(dá)式必產(chǎn)生一個(gè)結(jié)果，而結(jié)果必然有類型，類型是編譯時(shí)的東西，結(jié)果卻是運(yùn)行時(shí)的。像這種運(yùn)算表達(dá)式，它的最終類型是由其中每一步運(yùn)算所產(chǎn)生的結(jié)果所對(duì)應(yīng)的類型組合起來(lái)所決定的，類型確定的過(guò)程其實(shí)和表達(dá)式的識(shí)別是一致的。

VecTmp 對(duì)象在邏輯上其實(shí)也是一棵樹，它的成員變量 op1_, op2_ 則分別是左右兒子結(jié)點(diǎn)，樹的內(nèi)部結(jié)點(diǎn)代表一個(gè)運(yùn)算，葉子結(jié)點(diǎn)則為操作數(shù)，一遍中序遍歷下來(lái)，得到的就是整個(gè)表達(dá)式的值。

神奇的 boost::proto

expression template 是個(gè)好東西(就正如 expression SFINAE 一樣)，它能幫助你在編譯時(shí)建立非常復(fù)雜好玩的類型系統(tǒng)（從而實(shí)現(xiàn)很多高級(jí)玩意，主要是函數(shù)式)。但顯然如果什么東西都需要自己從頭開始寫，這個(gè)技術(shù)用起來(lái)還是很麻煩痛苦的，好在模板元編程實(shí)在是個(gè)太好玩的東西，已經(jīng)有很多人做了很多先驅(qū)性的工作，看看 boost proto 吧，在 c++ 的世界里再打開一扇通往奇怪世界的大門