Practical usage of cpp reference and move semantic 在優化重構一部分老代碼時，實際使用 c++ 的 reference 與 move semantic 遇到了若幹問題，在此記錄。 Aggregation 首先，數據的設計並不複雜，只有一個類，成員變數 ...
Practical usage of cpp reference and move semantic
在優化重構一部分老代碼時，實際使用 c++ 的 reference 與 move semantic 遇到了若幹問題，在此記錄。
Aggregation
首先，數據的設計並不複雜，只有一個類，成員變數為一個 std function 並需要在初始化時賦值。最初設計如下，
我希望盡一切可能避免保存 function 對象的副本，所以將函數參數與成員變數全部用 reference 表示。
class UniformValueWrapper {
public:
explicit UniformValueWrapper(const std::function<UniformValue(const JsonishValue *)> &parse_func) :
parse_func_(parse_func) {}
const std::function<UniformValue(const JsonishValue *)> &parse_func_;
};
// using
UniformValueWrapper wrapper([](const JsonishValue *jsonish) {
return UniformValue{jsonish->toJsonBool()->getBool()};
}
);
這樣的寫法編譯鏈接無誤，實際運行時，卡在實際真正調用這個函數的地方了。當然各個平臺由於編譯器和操作系統不
同可能有不同的表現，我相信在某些平臺我的代碼應該是直接 crash 的。那麼問題出在哪裡？我的預想是在構造函數中
傳遞 const ref 使其擴展局部變數（即提供的這個函數）的生命周期，使其可以保存在 UniformValueWrapper 這個
類的生命周期中。但是實際情況是，局部變數的生命周期只能維持到構造函數調用完成，所以在UniformValueWrapper
中的 ref member 雖然保存了原有的 reference 但是對應的實例在構造函數調用完成後就已經釋放。
實際上在 class member variable 使用 reference 的做法是 OOP 中的 aggregation.
In UML it is called aggregation. It differs from composition in that the member object is not owned by the referring class.
The main reason for aggregation is that the contained object is not owned by the containing object and thus their lifetimes are not bound. In particular the referenced object lifetime must outlive the referring one. It might have been created much earlier and might live beyond the end of the lifetime of the container.
所以生命周期問題是所有使用 aggregation 方式時需要時刻記在心裡的關鍵點。
針對我的使用場景，修改方法其實很簡單，就是放棄使用 aggregation 把 class member 的 reference 去掉。
modernize-pass-by-value
據上一章，我作如下修改：
class UniformValueWrapper {
public:
explicit UniformValueWrapper(const std::function<UniformValue(const JsonishValue *)> &parse_func) :
parse_func_(parse_func) {}
std::function<UniformValue(const JsonishValue *)> parse_func_;
};
這樣寫法沒有問題，但是 clang 編譯器提示 "Clang-Tidy: Pass by value and use std::move" 這裡很有意思了，
為什麼我所認為的使用 const reference 的寫法明明是高效傳遞變數，避免不必要的 copy 操作，為何讓我改用低效的
pass by value? 查了一下 Clang Tidy 的文檔，初看起來，兩種方式的區別在於 copy 發生的時機。
- 使用 const ref 的方式，在構造函數參數傳遞沒有 copy 但是在
parse_func_(parse_func)這裡進行了 copy - 使用 pass by value 方式，在構造函數參數傳遞時進行 copy 但是後面的 member initialize 改成了
parse_func_(std::move(parse_func))
那麼，實際上一次 copy 是無法避免的，只是在哪個時機發生而已，為什麼要求我們使用後一種方式呢？
這裡現代 C++ 編譯器有一個牛逼的優化，叫做 copy elision. 在一個聲明瞭 value 參數的函數中，當函數實際參數
是 rvalue 時，編譯器能判斷出多餘的 copy 操作，並主動忽略之，則在函數內直接使用了實參對象。這樣的做法和
const ref 似乎是一致的。其實 Return Value Optimization 也是 copy elision 的一個體現。那麼回到上面的問題，
當時機合適的時候，其實一次 copy 都沒有發生，直接就把函數參數 move 到了最終的地方。如果時機不合適，那麼
最差也就是和原來一樣，進行了一次 copy 操作。這就是為什麼推薦這樣寫的原因，編碼者不用費心去思考這個函數
實際調用時的情況，讓 Clang 來幫我們做判斷，我們這樣寫能保證最高效情況能出現，且最差情況也不會使其差過
原本的寫法。
摘錄一下黃金準則：
Guideline: Don’t copy your function arguments. Instead, pass them by value and let the compiler do the copying.
最終的代碼
class UniformValueWrapper {
public:
explicit UniformValueWrapper(std::function<UniformValue(const JsonishValue *)> parse_func) :
parse_func_(std::move(parse_func)) {}
std::function<UniformValue(const JsonishValue *)> parse_func_;
};
Ref:
- https://clang.llvm.org/extra/clang-tidy/checks/modernize-pass-by-value.html
- Want Speed? Pass by Value.
