前一陣子寫了一篇文章，提到語言進化的職責之一，就是去除語言中的tricks（職責之二是去除非本質復雜性）。
常看我blog的朋友肯定記得我曾寫過的boost源碼剖析系列。本來這個系列是打算成書的，但隨著對C++的熟悉發生了一些轉變，對語言級技術的熱衷逐漸消退，再回過頭來看boost庫中的一些組件，發現原本覺得很有寫的必要的東西頓時消失了。Scott Meyers的主頁上也列有一個寫Boost Under The Hood的計劃，一直也不見成文，興許也有類似的原因。
一門語言應該是“Make simple things simple, make complex things possible”的。當我們用語言來表達思想的時候，這門語言應該能夠提供這樣的能力：即讓我們能夠最直接地表達我們的意思，多一分則太多，少一分則太少，好比古人形容美女：增一分則太肥，減一分則太瘦。
這個問題上，有一個我認為是廣泛的誤解，就是“KISS便意味著要精簡語言，並避免在編碼中使用‘高階’語言特性”。對此有一句話我覺得說得好：你不能通過從一門語言中去掉東西來增加表達力。高階特性是一面利刃，用得不好固然傷了自己，但這並不表明就沒有用。任何東西都是在它真正適用的地方適用，霸王硬上弓的話弓斷弦崩反而傷及自身。所以，僅僅因為高階特性輕易誤用（而且高階特性的確也輕易吸引人去用且輕易誤用，不過這是另一個問題），就斷然在任何地方都不用並宣稱這樣才是KISS的話，便因噎廢食了。舉個例子，高階函數是有用的，假如在真正需要高階函數的地方不用高階函數，那不是KISS，只能讓解決方案（或者更確切地說，workaround）更復雜。lambda函數是有用的，但假如在真正需要lambda的地方不使用lambda，也只能導致更復雜更不直觀的workarounds。OOP是有用的，但假如你的程序本來就只是簡單的“數據+操作”你偏要硬上OOP的話，不僅多了編碼時間，而且還降低程序的可見度和可維護性，後者就意味著項目的money。拿C++來說，這是一個廣為诟病的問題。C++的偏向底層的應用領域決定了有不少地方使用C++其實就是“數據+操作”，然而很多人卻因為用的是C++編譯器，便忍不住去使用高級特性，結果把本來簡單的事情復雜化——我自己就有不少次這樣的經歷：用了一大堆類之後，做完了回過頭來再看，這些類都干嘛來著？需要嗎？最要害的就是要清楚自己做的是什麼事情，以及什麼工具才是對你所做的事情最適合的。
說到這裡不妨順便說說另一個誤解：“假如我反正用不著C++裡面的高級特性，那還不如用C罷了”，鑒於C/C++的應用領域，的確有不少地方是可以用C++的C部分完成得很好的，所以這個誤解被傳播得還是蠻廣泛的。這裡的一個微妙的忽視在於：用C的話，你就用不到許多很好的C++庫了。用C++的話，你完全可以在你自己的編碼中不使用高階特性（說實話，這需要清醒的頭腦和豐富的經驗，以及克制能力），但你還是可以利用眾多的C++庫來簡化你的工作的：假如一個transform明明可以搞定的你偏要寫一個for出來難道能叫KISS？假如一個vector就能避免絕大多數內存治理漏洞和簡化內存治理工作你偏偏要手動malloc/free那能叫KISS（我見過不少用C++編碼卻到處都是malloc/free的）？假如最直接的方式是gc你偏偏要繞一大堆彎子才能保證正確釋放那也不叫KISS（等C++09吧）。假如一個for_each(readdir_sequence(".", readdir_sequence::files), ::remove);能搞定的你偏要寫：
// in C
DIR* dir = opendir(".");
if(NULL != dir)
{
strUCt dirent* de;
for(; NULL != (de = readdir(dir)); )
{
struct stat st;
if( 0 == stat(de->d_name, &st) &&
S_IFREG == (st.st_mode & S_IFMT))
{
remove(de->d_name);
}
}
closedir(dir);
}
那能叫KISS？
總之還是那句話：明確知道你想要表達的是什麼並用最簡潔（在不損害輕易理解性的前提下）的方式去表達它。但我認為，最KISS不代表最原始。
進化——兩個例子
先舉一個平易近人的例子（Walter Bright——D語言發明者——曾在他的一個presentation中使用這個例子），假如我們想要遍歷一個數組，在C裡面我們是這麼做（或者用指針，不過指針有指針自己的問題）：
int arr[10];
… // initialize arr
for(int i = 0; i < 10; ++i)
{
int value = arr[i];
…
printf
}
這個貌似簡單的循環其實有幾個主要的問題：
1. 下標索引不應該是int，而應該是size_t，int未必能足夠存放一個數組的下標。
2. value的類型依靠於arr內元素的類型，違反DRY，假如arr的類型改變為long或unsigned，就可能發生截斷。
3. 這種for只能對數組工作，假如是另一個自定義容器就不行了。
在現代C++裡面，則是這麼做：
for(std::vector<int>::iterator
iter = v.begin();
iter != v.end();
++iter) {
…
}
其實最大的問題就是一天三遍的寫，麻煩。for循環的這個問題上篇講auto的時候也提到。
Walter Bright然後就把D裡面支持的foreach拿出來對比（當然，支持foreach的語言太多了，這也說明了這個結構的高效性）。
foreach(i; v) {
…
}
不多不少，剛好表達了意思：對v中的每個元素i做某某事情。
這個例子有人說太Na？ve了，其實我也贊成，的確，天天不知道有多少程序員寫下一個個的循環結構，究竟有多少出了上面提到的三個問題呢？最大的問題恐怕還是數組越界。此外大家也都親身體驗過違反DRY原則的後果：改了一處地方的類型，編譯，發現到處都是類型錯誤，結果一通“查找——替換”是免不了的了，誰說程序員的時間是寶貴的來著？
既然這個例子太Nave，那就說一個不那麼Nave的。Java為什麼要加入closure？以C++STL為例，假如我們要：
transform(v1.begin(), v1.end(), v2.begin(), v3.begin(), _1 + _2);
也就是說將v1和v2裡面的元素對應相加然後放到v3當中去。這裡用了boost.lambda，但大家都知道boost.lambda又是一個經典的雞肋。_1 + _2還算湊活，一旦表達式復雜了，或者其中牽涉到對其它函數的調用了，簡直就是一場噩夢，比如說我們想把v1和v2中相應元素這樣相加：f(_1) + f(_2)，其中f是一個函數或仿函數，可以做加權或者其它處理，那麼我們可以像下面這樣寫嗎：
transform(…, f(_1) + f(_2));
答案是不行，你得這樣寫：
transform(…,
boost::bind(std::plus<int>(), boost::bind(f, _1), boost::bind(f, _1))
);
Lisper們笑了，Haskeller們笑了，就連Javaer們都笑了。It’s not even funny! 這顯然違反了“simple things should be simple”原則。
假如不想卷入C++ functional的噩夢的話，你也可以這麼寫：
struct Op
{
int operator()(int a1, int a2) { return f(a1) + f(a2); }
};
transform(…, Op());
稍微好一點，但這種做法也有很嚴重的問題。
為什麼Java加入closure，其實還是一個語法問題。從嚴格意義上，Java的anonymous class已經可以實現出一樣的功能了，正如C++的functor一樣。然而，代碼是給人看的，語言是給人用來寫代碼的，代碼的主要代價在維護，維護則需要閱讀、理解。寫代碼的人不希望多花筆墨來寫那些自己本不關心的東西，讀代碼的人也希望“所讀即所表”，不想看到代碼裡面有什麼彎子，最好是自然語言自然抽象才好呢。
所以，盡管closure是一顆語法糖，但卻是一顆很甜很甜的糖，因為有了closure你就可以寫：
transform(…, <>(a1, a2){ f(a1) + f(a2) });
Simple things should be simple!
此外，closure最強大的好處還是在於對局部變量的方便的引用，設想我們想要創建的表達式是：
int weight1 = 0.3, weight2 = 0.6;
transform(…, f(_1)*weight1 + f(_2)*weight2);
當然，上面的語句是非法的，不過使用closure便可以寫成：
int weight1 = 0.3, weight2 = 0.6;
transform(…, <&>(_1, _2){ f(_1)*weight1 + f(_2)*weight2 } );
用functor class來實現同樣的功能則要麻煩許多，一旦麻煩，就會error-prone，一旦error-prone，就會消耗人力，而人力，就是金錢。
C++09也有希望加入lambda，不過這是另一個話題，下回再說。
The Real Deal——variadic templates
C++的callback類，Google一下，沒有一打也有半打。其中尤數boost.function實現得最為靈活周到。然而，就在其靈活周到的接口下面，卻是讓人不忍卒讀的實現；03年的時候我寫的第一篇boost源碼剖析就是boost.function的，當時還覺得能看懂那樣的代碼牛得不行...話說回來，那篇文章主要剖析了兩個方面，一個是它對不同參數的函數類型是如何處理的，第二個是一個type-erase設施。其中第一個方面就占去了大部分的篇幅。
簡而言之，要實現一個泛型的callback類，就必須實現以下最常見的應用場景：
function<int(int, int)> caller = f;
int r = caller(1, 2); // call f
為此function類模板裡面肯定要有一個operator()，然而，接下來，如何定義這個operator()就成了問題：
template<Signature>
class function
{
operator()(？？？);
};
？？？處填什麼？返回值處的？？？可以解決，用一個traits：typename result_type<Signature>::type，但參數列表處的？？？呢？
boost采用的辦法也是C++98唯一的辦法，就是為不同參數個數的Signature進行特化：
template<typename R, typename T1>
class function<R(T1)>
{
R operator()(T1 a1);
};
template<typename R, typename T1, typename T2>
class function<R(T1, T2)>
{
R operator()(T1 a1, T2 a2);
};
template<typename R, typename T1, typename T2, typename T3>
class function<R(T1, T2, T3)>
{
R operator()(T1 a1, T2 a2, T3 a3);
};
… // 再寫下去頁寬不夠了，打住…
如此一共N（N由一個宏控制）個版本。
這種做法有兩個問題：一，函數的參數個數始終還是受限的，你作出N個特化版本，那麼對N+1個參數的函數就沒轍了。boost::tuple也是這個問題。二，代碼重復。每個特化版本裡面除了參數個數不同之外基本其它都是相同的；boost解決這個問題的辦法是利用宏，宏本身的一大堆問題就不說了，你只要打開boost.function的主體實現代碼就知道有多糟糕了，近一千行代碼，其中涉及元編程和宏技巧無數，可讀性可以說基本為0。好在這是個標准庫（boost.function將加入tr1）不用你維護，假如是你自己寫了用的庫，恐怕除了你誰也別想動了。所以第二個問題其實就是可讀性可維護性問題，用Matthew Wilson的說法就是可發現性和透明性的問題，這是一個很嚴重的問題，許多C++現代庫因為這個問題而遭到诟病。
現在，讓我們來看一看加入了variadic templates之後的C++09實現：
template<typename R, typename... Args>
struct invoker_base {
virtual R invoke(Args...) = 0;
virtual ~invoker_base() { }
};
template<typename F, typename R, typename... Args>
struct functor_invoker : public invoker_base<R, Args...>
{
eXPlicit functor_invoker(F f) : f(f) { }
R invoke(Args... args) { return f(args...); }
private:
F f;
};
template<typename Signature>
class function;
template<typename R, typename... Args>
class function<R (Args...)>
{
public:
template<typename F>
function(F f) : invoker(0)
{
invoker = new functor_invoker<F, R, Args...>(f);
}
R operator()(Args... args) const
{
return invoker->invoke(args...);
}
private:
invoker_base<R, Args...>* invoker;
};
整個核心實現就這些！一共才36行！加上析構函數拷貝構造函數等邊角料一共也就70行！更重要的是，整個代碼清楚無比，所有涉及到可變數目個模板參數的地方都由variadic templates代替。“Args…”恰如其分的表達了我們想要表達的意思——多個參數（數目不管）。與C++98的boost.function實現真是天壤之別！
這裡function_invoker是用的type-erase手法，具體可參見我以前寫的boost.any源碼剖析，或上篇講auto的，或《C++ Template Metaprogramming》（內有元編程慎入！）。type-erase手法是像C++這樣的弱RTTI支持的語言中少數真正實用的手法，某種程度上設計模式裡面的adapter模式也是type-erase的一個變種。
假如還覺得不夠的話，可以參考variadic-templates的主頁，上面的variadic templates proposal中帶了三個tr1實現，分別是tuple，bind，function，當然，variadic-templates的好處遠遠不僅僅止於這三個實現，從本質上它提供了一種真正直接的表達意圖的工具，完全避開了像下面這種horrible的workaround：
template<class T1>
cons(T1& t1, const null_type&, const null_type&, const null_type&,
const null_type&, const null_type&, const null_type&,
const null_type&, const null_type&, const null_type&)
: head (t1) {}
tuple的C++98實現，代碼近千行。利用variadic-templates實現，代碼僅百行。
和這種更horrible的workaround：
template<class R, class F, class A1, class A2, class A3, class A4, class A5, class A6>
_bi::bind_t<R, F, typename _bi::list_av_6<A1, A2, A3, A4, A5, A6>::type>
BOOST_BIND(boost::type<R>, F f, A1 a1, A2 a2, A3 a3, A4 a4, A5 a5, A6 a6)
{
typedef typename _bi::list_av_6<A1, A2, A3, A4, A5, A6>::type list_type;
return _bi::bind_t<R, F, list_type>(f, list_type(a1, a2, a3, a4, a5, a6));
}
小小的boost.bind，實現代碼逾兩千行，其間重復代碼無數。用了variadic-templates，實現不過百行。
BTW. variadic templates在C++大會上一次性幾乎全數投票通過。lambda能不能進標准則要看幾個提案者的工作。目前還沒有Wording出來。不過只要出了wording想必也會像variadic templates那樣壓倒性通過的。
