C++17 新的數字、字串轉換函式庫：std::from_chars

在 C++ 裡面，其實已經有不少在字串與數字間轉換的方法了，像是 sprintf、sscanf、atol、strtol、stringstream、to_string 等等…

而在 Boost C++ Libraries 裡面，為了各種原因，也有另外提供 lexical_cast、Convert 等函式庫，讓使用者可以更方便地進行文字和數字間的轉換。

在 C++17 裡面，又有另一個標準的選擇了！那就是 std::from_chars()（參考）。

為什麼在已經有這麼多方法的情況下，還要再多弄一個出來呢？基本上，std::from_chars() 是一個相對低接、可以提供最好的效能的函式；或許使用上沒那麼便利，但是適用於非常在乎效能的時候。

廣告

使用 Visual Studio 編輯、預覽 Markdown 說明：Markdown Editor

「Markdown」這種標記語言（維基百科、常見附檔名是 .md），是一種輕量化的標記語言，可以用相對簡單的語法，來做出簡易的格式化文件。雖然他的語法有限，能呈現出的多樣性比不上 HTML + CSS 等複雜的語法，但是基本上對於要寫一般文件，也算夠用了。

而 Markdown 開始成為主流，在 Heresy 個人覺得，似乎還是因為 GitHub（官網）就是基於 MArkdown 的 GFM（GitHub Flavored Markdown、官方規格）來做預設的文件格式。

所以，如果要在這類的程式碼控管平台上撰寫說明文件的話，勢必得需要了解基本的 Markdown 語法。

用 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

在 Visual Studio 2017 建置 OpenCC

很久以前，Heresy 有寫過《OpenCC 簡易使用紀錄》這篇文章，簡單記錄當時使用 OpenCC 的情況了。而最近，由於又要改動相關的程式，所以就又需要重新建置它了。

但是沒想到，按照之前建置的方法，在 Visual Studio 2017 下，卻出現了一些問題…

問題主要有兩個：

1. PhraseExtract.cpp 這個檔案會出現 C2059、C2001 等語法錯誤
2. 編譯 Config.hcpp 的時候，VC 提供的 setjmp.h、csetjmp 兩個檔案出現 C3829 等錯誤

在 VIsual Studio 使用 Just My Code，避免 C++ 偵錯時顯示大量外部函式庫的內容

在使用 Visual C++ 開發程式的時候，其實有許多好用的偵錯工具，都可以幫助開發者找到程式的問題到底在哪；包括了各種中斷點、呼叫堆疊（call stack）、以及逐步執行（step）等等，能善用的話，都是很方便的工具。

但是，當外部函式庫使用多了之後，其實在使用呼叫堆疊和逐步執行的時候，往往會碰到一個問題，那就是外部函式庫會造成嚴重的干擾，讓偵錯變得相當麻煩…

比如說下面就是 Heresy 自己用 Boost Beast 來試著寫 WebSocket Server 時，中斷時的呼叫堆疊：

允許 32 位元應用程式使用 2GB 以上的記憶體

目前大部分的電腦系統，應該都已經從 32 位元轉換到 64 位元了，所以在開發應用程式的時候，其實在一定的程度上，可以「揮霍」記憶體。（笑

但是，有的時候受限於第三方函式庫，可能還是需要建置 32 位元的程式；實際上，Heresy 這邊最近就有碰到，因為廠商硬體的驅動程式的原因，無法把程式建置成 64 位元的版本。

而只能建置成 32 位元的最大問題，就是記憶體使用量大幅變小了…

基本上，在 Windows 環境下，32 位元的應用程式能使用的記憶體，最大就是 1.6GB 左右了；如果程式向系統要求要求超過 1.6GB 的記憶體，就會出錯了。

shared_ptr 的輔助類別 enable_shared_from_this

之前在《避免 memory leak：C++11 Smart Pointer》（上、下）這兩篇文章，已經大概介紹了 C++11 的智慧指標（smart pointer）了。而 C+11 提供的三種智慧指標裡面，可能被使用的機會最大的，應該還是 shared_ptr<>（參考）吧？

而最近在看 Boost 的 Beast 這個新的函式庫（官網）的時候，才注意到原來 C++11 還有提供一個 enable_shared_from_this<> 類別（參考），讓一個物件可以更安全地產生對應的智慧指標。

由於感覺還算滿有用的，所以這邊就稍微紀錄一下吧。

在 QTableView 內使用 QItemDelegate 來畫按鈕

QTableView 是 Qt 的一個 model / view 的表格元件（官方文件），如果搭配 QAbstractItemModel 來使用的話，其實還算簡單好用，甚至可以很簡單地做到多個表格間的資料同步。

而如果需要表格內不只想要顯示文字、而希望可以使用一般的 QWidget 的話呢，他其實也有提供 setIndexWidget() 這個函式（文件），可以針對每一個欄位，來設定要使用的 widget。

或者另一個選擇，就是放棄使用 QAbstractItemModel，改用 QTableWidget（參考），也是一個方法。

C++ 資料成員初始化 @ C++11/17（inline variable）

在 Heresy 來看，C++ 類別（或結構）的資料成員（data member）的初始化，其實一直很麻煩…因為要初始化他的值，不能像一般變數一樣，在宣告的同時就同時定義，變成要初始化的話，會變成一定要去定義類別的建構子才行…

以前的寫法，基本上就是：

class CTest
{
public:
	int m_iValue1;
 
public:
	CTest() : m_iValue1(128)  {}
};

這樣寫法一個比較麻煩的地方，就是如果有好幾個建構子的話，那每個建構子都給各自去給初始化的值。

C++ 的一些 attribute

C++ 的 attribute（參考）是在 C++11 新加入的東西。他基本上算是在程式碼裡面，加上特別的輔助說明，給編譯器看，讓編譯器可以在編譯時針對這些屬性來做處理。

這樣的功能其實以前編譯器大多是有自己定義。像 gcc 是用 __attribute__（參考）、MSVC 則是有 __declspec（參考），現在則算是終於有個統一的標準了。

目前 C++ attribute 的寫法滿特別的，他是直接用兩組中括號夾住、寫成 [[…]] 這樣的形式。而到 C++20 為止，也訂了超過十個 attribute 了（到還沒定案的 C++20）（除了標準定義的部分，編譯器也還有可以有自己定義的東西）；在大部分的狀況下，他們主要的功能大概就是避免編譯器產生不必要的警告、增加程式碼的可讀性，以及讓編譯器更好最佳化吧～

其中有的個人覺得還算滿有用的，所以這邊就大概紀錄一下。