我對C++的使用和理解是不斷變化的。從一開始的C with Class 到接觸到設計模式，才理解了什么叫真正的OOP；從接觸到STL才真正正視Template，了解了什么是GP；從Python和Golang的火熱中了解了函數作為first-class的力量；從某些文章對Lisp近乎玄學的推崇中知道了FP的優勢和它逐漸在主流的編程方式中興起的原因。
C++是包容和自由的，自從學了std::function和lambda之后，我也開始逐漸學著向FP方式轉變。因為在很多方面，將function作為first-class，對編碼帶來的不只是形式上的變化，更是思維方式的變化。
lambda與QObject::Connect
C++11lambda表達式和Qt5的搭檔，使得可以可以放棄SIGNAL、SLOT宏，采用一種更加直觀和簡潔的方式使用Connect。
使用lambda之前，如果要在Qt的main函數里使用slot，不得不另外構造一個類繼承QObject，并且定義槽函數，然后才能在main里實例化對象并綁定槽函數：
//myObject.h
#include <QObject>
class myObject : public QObject {
public:
myObject(QObject* parent = 0);
~myObject();
public slots:
void onClicked();
};
//myObject.cpp
......
void myObject::onClicked(){
qDebug() << "clicked";
}
//main.cpp
#include <QApplication>
#include <QDebug>
#include <QPushButton>
#include "myObject.h"
int main(int argc, char *argv[]) {
QApplication app(argc, argv);
QPushButton *button = new QPushButton("click");
button->show();
myObject *obj = new myObject();
QObject::connect(button, SIGNAL(clicked()), obj, SLOT(onClicked()));
return app.exec();
}
為了一個槽函數，還要引入另一個類，實在是大動干戈，而且還不直觀（這可能也是OOP為人詬病的一個方面吧）。在有了lambda之后，是這么干的：
#include <QDebug>
#include <QPushButton>
int main(int argc, char *argv[]) {
QApplication app(argc, argv);
QPushButton *button = new QPushButton("click");
button->show();
QObject::connect(button, &QPushButton::clicked, []() {
qDebug() << "clicked";
});
return app.exec();
}
簡潔！一目了然！！
虛函數與std::function
上面的例子其實還有類似的情況，在QWidget上想要自定義鼠標press事件，我們有兩種方式：
- 該widget外部使用eventfilter來攔截該widget的鼠標press事件并處理
- 自定義繼承自QWidget的widget類并覆蓋其
mousePressEvent()的虛函數
第一種方式不直觀，對該控件的處理要到別的地方去尋找，不是很“OOP”；第二種方式和上一例子一樣，代價有點大。
其實這樣的例子還有很多。傳統的OOP在解耦的同時一定會導致體型的臃腫，除此之外還經常會有將處理流程隱藏在層層的封裝和繼承之中導致的不直觀不清晰的問題。
代碼說到底是人來寫人來讀的，任何反直觀的都是不好的。編程就像寫文章，詰屈聱牙的東西沒人愿意看，好的代碼一定是讀起來酣暢淋漓的。
如果我們自己實現一個Button類，可以是這樣的：
//Button.h
class Button {
......
virtual void onClicked() = 0;
};
//MyButton.h
class MyButton : public Button {
......
void onClicked(){
//需要的操作
}
};
這樣，在我們需要一個Button的時候，新寫一個類繼承Button，將點擊的處理寫在onClicked方法內即可。可以，這很“OOP”。
現在呢，我們可以利用std::function，使得函數作為類成員，像對待類的普通成員一樣對函數成員進行賦值操作，即可得到我們需要的對象：
//Button.h
class Button {
......
std::function<void()> _onClicked;
};
//在使用的地方
Button btn;
btn._onClicked = [](){
//需要的操作
};
喏，更加的簡單明了。函數不需要通過繼承來特化，而是通過像普通變量一樣的方式直接實例化，帶來的不光是結構 上的簡單，還有語意上的直白。
ScopeGuard
資源的釋放從來都是一個問題。文件句柄、鎖、等等資源，申請的時候我們可能想著一會兒用完要釋放，等到用完之后可能就忘了，或者是因為分支處理漏掉了，這都是很有可能發生的，就算沒有在分支處理中漏掉，在各個分支里都重復的寫同樣的釋放資源的代碼也很不fashion，沒人愿意當CV戰士。
利用RAII特性，局部變量析構時候釋放資源已經成為一個通用做法。麻煩的是我們需要為各種資源都創建類來利用其析構函數釋放資源，太麻煩。現在有了std::function就好了，借鑒一下std::lock_guard，就有了下面的做法：
//ScopeGuard.h
class ScopeGuard {
public:
explicit ScopeGuard(std::function<void()> callback)
: _onExit(callback) {};
~ScopeGuard(){
_onExit();
};
private:
std::function<void()> _onExit;
};
#define ON_SCOPE_EXIT(callback) ScopeGuard EXIT##__LINE__(callback)
//在使用的地方
{
HANDLE f = fopen("conf.yaml");
ON_SCOPE_EXIT([=](){
fclose(f);
});
......
{
_mutex.lock();
ON_SCOPE_EXIT([&](){
_mutex.unlock();
});
......
}
......
}
資源創建之后，立即跟在后面寫釋放方式，不會忘不會漏，看起來還明確。
ON_SCOPE_EXIT宏作用在于創建了一個ScopeGuard局部變量；變量名由行號確定，避免了多個ScopeGuard重名的問題。
其它
將function作為first-class帶來的改變還有很多，比如將function保存在容器中，將function作為值傳遞給別的線程執行，返回閉包來創建累加器等等。
初極狹，才通人。復行數十步，豁然開朗。
