更多元的函式回傳型別:optional 與 outcome

一般當在設計函式介面的時候,都會直接把結果回傳出來;比如說:

int compute(const int input)
{
  return 100 / input;
}

這樣的設計非常直覺,但是像以上面的例子來說,如果 input 是 0 的時候,這個函式就會產生例外狀況(exception)了。

而如果我們想要用 exception 以外的形式,來處理這類的錯誤的話,通常就需要修改函式的介面,讓他可以回傳執行的狀況。

閱讀更多»

儲存 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

閱讀更多»

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」的錯誤。

閱讀更多»

C++11 的錯誤碼標準 part 3:補充與實作

針對 C++11 提供的 <system_error> 這個函式庫,Heresy 之前已經在 part 1 寫了 error_code 的基本使用,也在 part 2 寫了 error_condition 的東西。而在 part 2 的時候也有提到,由於 Heresy 在寫 part 1 的時候,其實對於 std::error_codestd::error_condtion 的關係有點誤解,導致有一些東西沒講到,所以這邊就先回到 std::error_code 的部分,做一些補充。

首先,之前在實作 error_code 的時候,總共實作了:

  • enum class ErrorCode
  • class ErrorCategory
    • message()
    • name()
  • make_error_code()
  • is_error_code_enum<Heresy::ErrorCode>

閱讀更多»

C++11 的錯誤碼標準 part 2:error_condition

這篇是延續之前的《C++11 的錯誤碼標準:error_code》一文,繼續來講 <system_error> 裡的另一個類別、std::error_condition文件)。

不過老實說,Heresy 在繼續寫這篇的時候,才發現之前對於這邊的設計有些誤解,所以其實在 error_code 這篇文章有的內容可能不夠完整,預計會在用第三篇文章繼續補齊。

error_conditionerror_code 非常地接近,不管是實際儲存的資料,或是介面的設計,基本上都沒有太大的差異;兩者的差別,主要是概念上、使用時機的差別。

兩者的差異,主要是:

  • error_code 基本上是比較底層的錯誤碼,針對有可能會因為作業系統實作的不同
  • error_condition 則是和平台差異無關(platform-independent)的錯誤碼,主要是用來做比較用的

閱讀更多»

C++11 的錯誤碼標準 part 1:error_code

<system_error> 這個函式庫是 C++11 時,加入標準函式庫裡的一個功能(C++ Referencecplusplus),主要是為了在 exception 以外,提供一個更有架構、同時也有擴展能力的錯誤回報機制。

為什麼不都用 exception 呢?主要是因為並不是所有的錯誤都是例外。
像是以網路的程式來說,有一些錯誤狀況,會是有相當高的發生機會、本來就應該要在程式的流程中被考慮到的、而不應該用例外來處理。

所以在這種狀況下,使用 exception 來處理這些錯誤狀況,並不見得是個好的方法。

<system_error> 最初是 Boost C++ Libraries 中的東西(參考),後來才被整合到 C++11 裡的,所以如果有在用 Boost 的話,對他應該不至於太陌生;像是在 Boost::ASIO(參考)裡面,主要就是透過 error_code 來做錯誤的回報。

閱讀更多»

VisualStudio 的視覺化偵錯工具:Graphical Debugging

「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 的型別來做監看的修飾,但是看來現在功能多了很多了~

閱讀更多»

用 Boost::Beast 刻的 Http Client

這篇算是簡單紀錄一下,Heresy 自己用 Boost::Beast(官網)刻出來的簡易的 C++ Http client 端函式庫。

Heresy 自己會寫這個,主要是因為有寫一個小程式,去把特定網站的內容,自動下來後重新整理、再轉換成電子書的格式給 Kindle 用。

其實第一個版本,Heresy 是用 Boost::asio(官網)來寫的;但是後來那個網站改成 HTTPS 了,所以程式就不能用了…拖了好一陣子後,Heresy 終於下定決心,改用 Boost::Beast 這個稍微高階一點的函式庫,來重寫 Http 的部分了。 ^^"

相關的檔案都放在:

https://github.com/KHeresy/HttpClientLite

閱讀更多»

Boost 的另一個型別轉換函式庫:Convert

在幾年前,Heresy 曾經寫了一篇《在文字和數字間轉換:boost::lexical_cast》,來介紹 Boost C++ Libraries 裡的 lexical_cast 這個函式庫;他的基本功能,就是來將文字、和其他的資料型別做轉換。

在 Heresy 當時看來,這個函式庫算是相當方便的~就算是自定義的型別,也可以透過實作 operator << 和 >> 來支援 lexical_cast。整體來說,他應該是可以簡化一些型別轉換時的程式寫法的。

不過,他還是有一些限制與問題在。除了效能不算很好外,他的錯誤處理方法也只有 exception 一種,此外更不支援格式化的設定,這讓他在某些情況下,不是很好用。

所以,在 Boost 1.59.0 的時候,Boost 又加入了另一個名為「Convert」的函式庫(官網),希望可以解決 lexical_cast 的這些問題。

閱讀更多»