一般當在設計函式介面的時候，都會直接把結果回傳出來；比如說：
int compute(const int input) { return 100 / input; }
這樣的設計非常直覺，但是像以上面的例子來說，如果 input 是 0 的時候，這個函式就會產生例外狀況（exception）了。
而如果我們想要用 exception 以外的形式，來處理這類的錯誤的話，通常就需要修改函式的介面，讓他可以回傳執行的狀況。
分類：C++
C++ 相關
儲存 C++ 的類別資料：Boost Serialization（part 2）
前一篇 part 1 大致上把 Boost serialization 的基本使用整理了一下。接下來這篇，就繼續整理一下其他的東西吧～
將 serialize() 改成 private
首先，在之前提到的例子裡面，如果是選擇在類別中定義成員函式 serialize() 的時候， 是直接把它定義成 public 的。
但是考慮到這個函式的特殊性，或許他並不適合做為一個外部可以直接呼叫的 public 函式。
所以這邊比較好的做法，應該是將它改為 private、並透過設定 friend class、來讓它可以被 Boost serialization 提供的 archive 呼叫，理論上會比較安全。
儲存 C++ 的類別資料：Boost Serialization（part 1）
「Serialization」（序列化、維基百科）在程式語言裡面，基本上是一種用來把資料結構或是物件的狀態，轉換成可儲存、可交換的格式的一種方法。
透過這樣的功能，可以把物件的狀態儲存下、之後再還原回來。
XML、JSON 這類的格式，實際上都可以算是序列化資料格式的一種。
而在 C++ 的標準函式庫中，並沒有提供相關的功能，所以這邊 Heresy 是找 Boost C++ Libraries 的 Boost.Serialization 來用了。
他的官方文件是：https://www.boost.org/libs/serialization/doc/index.html
C++20 正式定案！
C++ 在繼 C++17 之後，下一個新的標準 C++20 終於定案了！Heresy 看到的主要是《2020-02 Prague ISO C++ Committee Trip Report — C++20 is Done! 》這篇文章。
在文章中，他列了一些值得注意的 C++ 20 新功能如下：
C++20 concepts：定義的方式（part 2）
在前一篇《template 型別的需求描述：C++20 concepts（part 1）》，基本上算是簡單介紹了一下 Heresy 知道的 C++20 concepts 的使用概念。
而怎麼制定自己需求的 concept 呢？這邊來稍微整理一下。
首先，C++20 有提供 <concepts> 這個函式庫（參考），提供一些常見的概念，可以來直接使用。而實際上，裡面有很多是使用 C++11 的 <type_traits>（參考）的功能來做的；如果要自行定義 concept 的話，<concepts> 和 <type_traits> 應該都是有幫助的。
Concept 的語法基本上如下：
template<template_parameter_list> concept concept_name = constraint_expression;
template 型別的需求描述：C++20 concepts（part 1）
Template 是 C++ 一個泛型的重要功能。透過 template 可以讓開發者只要寫一次，就可以針對不同的型別的資料，來做處理。
他雖然用起來很方便，但是大部分情況下都缺少對於需求型別的描述，所以如果沒用好寫錯了，就很有可能因為使用了不符合需求的型別，而導致無法正確編譯；而這個時候，編譯器給個錯誤訊息往往也會過於雜亂、讓開發者難以理解、也難以找到真正的問題點。
比如說下面這個簡單的範例程式：
Visual C++ 2017 的 Docker 建置環境
前一篇《GitLab CI + Windows Docker 的一些紀錄》的時候，Heresy 已經大概有說明最近在玩 GitLab CI/CD，並試著拿 Docker 來做 Runner 時、在 Windows 平台上碰到的一些狀況了。
當時本來是想放棄的，不過後來還是繼續玩下去了；而玩了一個多禮拜，也總算是把整個環境初步完成了。
而這篇，就來分享一下，Heresy 這邊建置出 Visual C++ 2017 建置環境的 Docker 映像檔的紀錄。
首先，微軟官方其實針對怎麼建立包含 Visual Studio 的 Docker 映像檔有好幾個地方都有範例（範例一、範例二、範例三），內容基本上都相當地類似。
Heresy 這邊最後能用的範例，是基於 dotnet-framework:3.5-sdk-windowsservercore-1709 的版本（連結），其內容如下：
C++11/14 literals：part 2
針對 C++11／C++14 的 literals，前面已經寫了 part 1 來針對標準提供的 literals 做了一些說明；而接下來這篇，則是來紀錄一下如何自訂屬於自己的 literals、也就是所謂「User-defined literals」（CppReference）。
在定義 User-defined literals 的時候，能支援的格式是有限制的，包括了：
- 整數：(unsigned long long int)
- 浮點數：(long double)
- 字元：(char)、(wchar_t)、(char16_t)、(char32_t)
- 字串：(char,size_t)、(wchar_t,size_t)、(char16_t,size_t)、(char32_t,size_t)
如果不是這些型別的話，是不能編譯的。
Boost ASIO WebSocket Server 網站憑證設定
Heresy 這邊很早之前，就有開始使用 WebSocket++ 來開發自己的 WebSocket Server；而後來其實也有改用 Boost.Beast 來做同樣的工作。而這兩套函式庫的底層，其實都是 Boost::asio（官網），所以其實在某些地方還滿接近的。
而之前用起來都還算很正常，不管是老老的 IE 還是 Chrome 都可以使用，在有申請 SSL 憑證的情況下，就算建立加密的 WSS 也是可以正確使用的。
但是，前陣子當想使用 node.js（官網）來進行 WebSocket 的連線的時候，卻發現會出現「unable to verify the first certificate」的錯誤。
GitLab 的 C++ CI/CD 腳本：使用 PowerShell
之前已經在《GitLab 簡單的 C++ 專案腳本範例》這篇文章裡面，大概整理了一下 Heresy 這邊針對自己的 C++ 專案、撰寫出來的 GitLab CI 自動建置的腳本了。
不過，當時在 Windows 平台下，Heresy 是使用「Windows Batch」（CMD）這個 shell 來進行操作的。
但是，GitLab 官方其實有說，從 11.11 開始，就將「Windows Batch executor」設定為棄用（deprecated），並將於 13.0 時移除（預計時間是 2020/06/22）；而取而代之的，GitLab 將使用 PowerShell 來作為 Windows 上預設的 shell。（參考）
而這篇記錄，就是簡單地記錄一下 Heresy 把之前 cmd 的 script、改寫成 PowerShell 版本的紀錄。
