之前有寫了一篇《在 Windows 命令提示字元安裝 Qt SDK》，大概紀錄了一下，在沒有圖形介面的環境下，使用腳本來安裝 Qt SDK 的方法。
腳本在當時是沒問題的，但是沒想到前幾天要用的時候，卻發現又無法使用了…
網路上找了一下資料，發現似乎是在過沒幾天、Qt 把安裝程式更新到 3.1.x 後，又改了一些東西造成的。（拜託顧一下相容性啊…）
找到的資料是 StackOverflow 上的《Bypassing “User Data Collection" screen》這個回應。根據他的說法，這次改版主要是加入了「User Data Collection」的畫面，另外在選擇元件的部分也多了分類的選擇。
也因此，腳本要針對這兩個變化，做出修改：
這篇算是《GitLab CI + Windows Docker 的一些紀錄》的延伸。由於 Heresy 這邊的開發專案有用到 Qt SDK（官網），所以在建置用的 Docker 容器裡面，也需要安裝 Qt 的 SDK。
但是由於 Qt 現在的線上安裝程式也都是以圖形介面為主，並在圖形介面中選擇要安裝那些套件；所以要怎麼在沒有圖形介面的 Docker 內安裝，就需要稍微研究一下了。
在找了一些資料後，可以知道 Qt 的安裝程式框架（Qt Installer Framework、QTIFW、官方文件）是有支援使用腳本（script）來做控制的！（官方文件）
而在網路上，也可以找到使用這樣的機制，來自動安裝 Qt 的腳本範例。Heresy 這邊是參考《How can I install Qt 5.2.1 from the command line in Cygwin?》的例子。
Heresy 這邊很早之前，就有開始使用 WebSocket++ 來開發自己的 WebSocket Server；而後來其實也有改用 Boost.Beast 來做同樣的工作。而這兩套函式庫的底層，其實都是 Boost::asio（官網），所以其實在某些地方還滿接近的。
而之前用起來都還算很正常，不管是老老的 IE 還是 Chrome 都可以使用，在有申請 SSL 憑證的情況下，就算建立加密的 WSS 也是可以正確使用的。
但是，前陣子當想使用 node.js（官網）來進行 WebSocket 的連線的時候，卻發現會出現「unable to verify the first certificate」的錯誤。
這篇算是之前《使用 enum class 取代傳統的 enum》的後續。
當時介紹的 enum class 基本上是 C++11 引入、強化列舉型別的型別強度的設計；透過這樣的設計，可以避免一些程式設計上可能會碰到的問題。
但是，當 Heresy 後來實際要使用的時候，才發現 enum class 在某些方面上，似乎還有一些地方沒辦法和 enum 一樣地使用。
其中一個比較大的困擾，就是 enum class 沒有預設提供 bitwise operation，所以沒辦法直接把 enum class 當成 bitmask 來用。
針對 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 就曾經曾對 C++11（當時還叫做 C++0x）的新語法、Lambda Experssion 寫過簡單的介紹、《C++0x：Lambda expression》了～
由於 lambda 這種匿名函式再搭配需要使用 function object 的時候，會是一個相當方便的東西，所以 Heresy 也常常在使用。
而在 C++11 引進後，其實在後面的 C++14 和 C++17 中，也都有針對 lambda 再做一些改進；雖然之前其實也有簡單提過，不過這邊就在整理一下，這兩次改版中，Heresy 個人覺得比較用的到的變化吧～
VisualStudio 目前在 C++ 的部分，可以針對程式，建置出 32 位元（x86）和 64 位元（x64）的程式。
不過實際上，微軟有提供 32 位元以及 64 位元的建置工具、兩者都可以建置出 x86 以及 x64 的程式。也就是說，使用 32 位元的建置工具不但可以建置出 x86 的程式，也可以建置出 x64 的程式；同樣的，64 位元的建置工具，也可以建置出 x86 / x64 的程式。
而微軟目前基本上針對 VisualStudio 的 IDE 圖形介面，基本上都還是僅有 32 位元的版本、並沒有 64 位元的版本。
另外，微軟在透過 IDE 來建置的時候，就算是要建置 x64 的程式，預設也都是會去使用 32 位元的建置工具、來建置 x64 的程式（x86_x64 Cross Tools）。
