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

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

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

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)(除了標準定義的部分,編譯器也還有可以有自己定義的東西);在大部分的狀況下,他們主要的功能大概就是避免編譯器產生不必要的警告、增加程式碼的可讀性,以及讓編譯器更好最佳化吧~

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

閱讀更多»