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

閱讀更多»

C++14 與 C++17 Lambda Expression 的改變

在很久以前,Heresy 就曾經曾對 C++11(當時還叫做 C++0x)的新語法、Lambda Experssion 寫過簡單的介紹、《C++0x:Lambda expression》了~

由於 lambda 這種匿名函式再搭配需要使用 function object 的時候,會是一個相當方便的東西,所以 Heresy 也常常在使用。

而在 C++11 引進後,其實在後面的 C++14C++17 中,也都有針對 lambda 再做一些改進;雖然之前其實也有簡單提過,不過這邊就在整理一下,這兩次改版中,Heresy 個人覺得比較用的到的變化吧~

閱讀更多»

在 VisualStudio IDE 使用 64 位元 C++ 原生編譯環境

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)。

閱讀更多»

使用 enum class 取代傳統的 enum

「Scoped and strongly typed enums」是 C++11 時所引進的一個新的功能,主要是要取代舊的列舉型別(enum)。

他的基本用法,是在 enum 後面,再加上 classstruct;而要使用定義的值的時候,一定要加上範圍(scope、這邊就是 class 的名稱)。

下面就是簡單的比較:

enum
enum class
enum EColor
{
	RED,
	GREEN,
	BLUE
};
 
EColor eColor = RED;
enum class EColor
{
	RED,
	GREEN,
	BLUE
};
 
EColor eColor = EColor::RED;

閱讀更多»

在程式離開範圍時,自動執行動作:GSL finally

之前已經大概介紹過 C++ Guidelines Support Library 這個簡單的函式庫了;當時,也有簡單地介紹一下裡面的 owner<T>

而這一篇,則是來講一下一個 Heresy 個人覺得還滿實用的東西:finally

當在寫程式的時候,常常會在某個地方,需要建立很多臨時性的資源、來做計算、儲存,而當結果計算出來後,這些東西就需要被釋放掉。

如果程式的路線很簡單,只有一條線的話,其實很好處理、不太會成為問題;但是如果是一個函式,可能會有好幾條路線、甚至會提早 return、結束函式的話,要怎麼比較好地去把這些臨時性的資源清理掉,就會是個問題了。

閱讀更多»

C++ Guidelines Support Library

Heresy 在 2015 曾經簡單介紹過《C++ Core Guidelines》(官方)了。而實際上,他的整份文件很多條目,老實說要全部看過(理解)要相當的時間,也有相當的難度,所以 Heresy 後來其實也沒很認真去碰。

如果對內容有興趣的話,可以參考「Modernes C++」這個網站(連結),他有針對 C++ Core Guidelines 撰寫了大量的文章(分類),應該算是可以輔助閱讀的資料。

閱讀更多»