之前在《更多元的函式回傳型別：optional 與 outcome》這篇文章中，曾經提過在函式需要回傳計算的結果，但是又可能需要回傳處理的狀態（包含錯誤）的時候，除了可以使用簡單的 C++17 的 std::optional 來處理沒有辦法回傳值的狀況外，下面就是一個簡單的例子：
#include <iostream> #include <optional> std::optional<int> compute_opt(const int input) { if (input == 0 || input > 100) return std::nullopt; return 100 / input; } int main(int argc, char** argv) { auto optRes = compute_opt(101); if (optRes) std::cout << "OK: " << *optRes << std::endl; else std::cout << "Error" << std::endl; }
C++ 的標準函式庫雖然一直以來都有提供 <algorithm> 這個函式庫（參考），可以來做某些處理；而裡面其實也有像是 std::for_each()（參考）或 std::for_each_n()（參考）這類的函式、可以用來掃完整個陣列。
但是由於這些演算法大多是針對 iterator 來進行操作，在很多需要使用索引值（index）來存取周圍的資料時，會變得相對麻煩；也因此，其實 Heresy 這邊大多會使用傳統的 for 迴圈、或是 C++11 的 range-base for-loop 來寫，而很少會去用 std::for_each()。
也因此，當 C++17 開始正式針對部分也算法提供平行化的能力的時候（參考），雖然高興了一陣子，但是卻也發現有點難以使用…
一般當在設計函式介面的時候，都會直接把結果回傳出來；比如說：
int compute(const int input) { return 100 / input; }
這樣的設計非常直覺，但是像以上面的例子來說，如果 input 是 0 的時候，這個函式就會產生例外狀況（exception）了。
而如果我們想要用 exception 以外的形式，來處理這類的錯誤的話，通常就需要修改函式的介面，讓他可以回傳執行的狀況。
前一篇 part 1 大致上把 Boost serialization 的基本使用整理了一下。接下來這篇，就繼續整理一下其他的東西吧～
首先，在之前提到的例子裡面，如果是選擇在類別中定義成員函式 serialize() 的時候， 是直接把它定義成 public 的。
但是考慮到這個函式的特殊性，或許他並不適合做為一個外部可以直接呼叫的 public 函式。
所以這邊比較好的做法，應該是將它改為 private、並透過設定 friend class、來讓它可以被 Boost serialization 提供的 archive 呼叫，理論上會比較安全。
「Serialization」（序列化、維基百科）在程式語言裡面，基本上是一種用來把資料結構或是物件的狀態，轉換成可儲存、可交換的格式的一種方法。
透過這樣的功能，可以把物件的狀態儲存下、之後再還原回來。
XML、JSON 這類的格式，實際上都可以算是序列化資料格式的一種。
而在 C++ 的標準函式庫中，並沒有提供相關的功能，所以這邊 Heresy 是找 Boost C++ Libraries 的 Boost.Serialization 來用了。
他的官方文件是：https://www.boost.org/libs/serialization/doc/index.html
Heresy 這邊很早之前，就有開始使用 WebSocket++ 來開發自己的 WebSocket Server；而後來其實也有改用 Boost.Beast 來做同樣的工作。而這兩套函式庫的底層，其實都是 Boost::asio（官網），所以其實在某些地方還滿接近的。
而之前用起來都還算很正常，不管是老老的 IE 還是 Chrome 都可以使用，在有申請 SSL 憑證的情況下，就算建立加密的 WSS 也是可以正確使用的。
但是，前陣子當想使用 node.js（官網）來進行 WebSocket 的連線的時候，卻發現會出現「unable to verify the first certificate」的錯誤。
針對 C++11 提供的 <system_error> 這個函式庫，Heresy 之前已經在 part 1 寫了 error_code 的基本使用，也在 part 2 寫了 error_condition 的東西。而在 part 2 的時候也有提到，由於 Heresy 在寫 part 1 的時候，其實對於 std::error_code 和 std::error_condtion 的關係有點誤解，導致有一些東西沒講到，所以這邊就先回到 std::error_code 的部分，做一些補充。
首先，之前在實作 error_code 的時候，總共實作了：
這篇是延續之前的《C++11 的錯誤碼標準：error_code》一文，繼續來講 <system_error> 裡的另一個類別、std::error_condition（文件）。
不過老實說，Heresy 在繼續寫這篇的時候，才發現之前對於這邊的設計有些誤解，所以其實在 error_code 這篇文章有的內容可能不夠完整，預計會在用第三篇文章繼續補齊。
error_condition 和 error_code 非常地接近，不管是實際儲存的資料，或是介面的設計，基本上都沒有太大的差異；兩者的差別，主要是概念上、使用時機的差別。
兩者的差異，主要是：
<system_error> 這個函式庫是 C++11 時，加入標準函式庫裡的一個功能（C++ Reference、cplusplus），主要是為了在 exception 以外，提供一個更有架構、同時也有擴展能力的錯誤回報機制。
為什麼不都用 exception 呢？主要是因為並不是所有的錯誤都是例外。
像是以網路的程式來說，有一些錯誤狀況，會是有相當高的發生機會、本來就應該要在程式的流程中被考慮到的、而不應該用例外來處理。
所以在這種狀況下，使用 exception 來處理這些錯誤狀況，並不見得是個好的方法。
而 <system_error> 最初是 Boost C++ Libraries 中的東西（參考），後來才被整合到 C++11 裡的，所以如果有在用 Boost 的話，對他應該不至於太陌生；像是在 Boost::ASIO（參考）裡面，主要就是透過 error_code 來做錯誤的回報。
「Graphical Debugging」（網頁）是 VisualStudio 的一個延伸模組，它的功能是可以把 C++ 與 C# 中特並類型的資料、視覺畫出來、方便在偵錯的時候觀察。官方的說明是：
Visualization of C++ and C# variables during debugging, e.g. Boost.Geometry models, containers of values, arrays of points, etc.
Heresy 最早看到是很久以前的「Boost Debugger visualizers」（網頁），最初應該是只有針對 Boost C++ Libraries 的型別來做監看的修飾，但是看來現在功能多了很多了～
Heresy's Space 