解決 g++ 連結程式時的循環相依性的問題

在寫 C++ 的程式的時候，如果有拆分模組，有的時候會導致不同模組／函式庫之間的相依性變得很複雜、甚至可能會產生彼此互相相依的狀況（circular dependencies、維基百科有提供例子）。

在 Visual C++ 的環境下，linking 階段似乎是沒有順序、而且不會因為連結的順序、導致找不到參考的狀況。

但是在 g++ 的環境下，由於他的連結是有順序性的，所以如果加上 -lXXX 的順序不對，就可能會出現找不到參考的問題（錯誤訊息是「undefined reference」）。
比如說如果 libA 有用到 libB 的函式的話，那在連結的時候，libA 就必須要在 libB 的前面。

廣告

檢查網頁的表單資料的方法紀錄

這篇算是自己在幫不是自己寫的網站找 Bug 的時候，找的一些方法的紀錄。

基本上，主要是從前一陣子開始有在用某些政府單位的網站系統，結果被告知送出的表單內容出了一堆錯誤，結果搞到自己火大，只好自己開始找錯誤是怎麼發生的了。

由於網頁不是自己寫的，後台也沒有權限看，也沒有系統可以查詢，所以只好靠瀏覽器來找看看表單送出的狀況了。

由於操作系統時是使用 Google Chrome，所以接下來要找問題，當然也就是使用 Chrome 了；而基本上的操作，都是按下 F12 叫出 DevTools 後再開始的～

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（參考），也是一個方法。