自學程式誌

當你使用boost動態連結函式庫時，編譯時會出現以下的錯誤代碼嗎? error C1189: #error :  "Mixing a dll boost library with a static runtime is a really bad idea..." 的確，boost 自動連結功能(auto-linking) 帶給我們便利性，節省專案設置的時間，然而如何正確設定專案就成為很重要課題。以上錯誤代碼C1189意思是『 用靜態Runtime混合boost動態連結庫真的昰一個錯誤想法 』，也就是說Boost動態連結的專案屬性設置錯誤。 設定Boost動態連結的專案屬性主要有以下的步驟: 在前置處理器，強制動態連結Boost函式庫 在Code Generation選擇Runtime Library 增加Boost標題檔和函式庫的路徑 錯誤代碼C1189就是在第二步Runtime Library設定錯誤，此步驟主要設定在多執行緒模式下如何連結C和C++執行函式庫(C and C++ Runtime Library)，依據偵錯和發佈(Debug & Release)和靜態和動態函式庫(Static & Dll函式庫)主要分成以下四種: Multi-threaded (/MT) Multi-threaded Debug (/MTd) Multi-threaded DLL (/MD) Multi-threaded Debug DLL (/MDd) 簡單來說，若字尾帶有-d即偵錯版，沒有小寫d即發佈版。還有，判斷動態連結庫依據是多執行緒(Multi-threaded)後面是否有DLL，即縮寫為(/MD)，而靜態連結則是直接為多執行緒縮寫(/MT)。 環境 Windows 7 64 bit VS C++ 2015  方案:ThirdPartyExample 專案名稱：TestBoost_Dynamic 專案配置：Win32 Debug & Release Boost   1.59.0 下載教學： Boost簡介與分割 所使用到動態連結程式庫(dll) Boost.System Boost.DateTime Boost.Reg

你曾經認為Boost 函式庫過於龐大，而不敢使用嗎? 官方編譯好Boost函式庫 解壓縮大約有28GB，因為此龐大函式庫是由不同IDE版本編譯出來。首先，請根據你所設定的環境，取出Lib和Header資料夾，將大小減少到2.2GB。 請問將下圖所有函式庫上傳，讓團隊其他人自行決定如何使用，這是好的專案管理嗎？ 答案是非常差！！！ 首先，上圖是依據專案編譯屬性所分類的函式庫，詳細請參考以下的命名規則。因此若你將所有函式庫上傳，你無法清楚告知其他人如何在新專案正確地設定編譯屬性去連結函式庫。編譯屬性不同會改變產品發佈原則，部署人員必須花時間重新打包，而且產品發佈也缺少一致性。 舉例來說，圖二某人決定新專案有以下三個設定： 靜態連結 Boost函式庫 只使用Boost 裡面的三種函式庫 動態連結C++標準庫 然而，產品發佈原則是跨平台和獨立運行的應用程式，並且不會受更新IDE所影響，請問以上的設定是對的嗎？ 錯， 因為動態連結C++標準函式庫代表客戶開發機必須安裝 『 Visual C++ 可轉散發套件(Visual C++ Redistributable Packages ) 』，所以 產品發佈時 必須將 VS2015 的 Visual C++ 可轉散發套件 和應用程式一起打包安裝檔。 此套件會隨著IDE 更新 有所改變 。 也就是說， 每次開發者更換IDE，部署人員就必須 重新打包 ， 無形中增加專案時間成本。所以，篩選函式庫不但能讓其他人清楚如何正確使用，而且也減少第三方函式庫大小。 圖二 . 已分割Boost函式庫 另一方面，Boost目前是 『 準 』 函式庫，某些函式庫並不適合在產品開發上，而且Boost有些功能專案已實作，若不篩選Boost函式庫將導致一種功能有兩份程式碼。舉例來說，專案已經實作產生UUID的API，但是沒有文件說明產生UUID，你分派新人任務產生UUID時，你認為他會怎麼做？ 若參考StackOverflow答案，新人就直接使用boost::uuids::random_generator，不但增加引用Boost標頭文件，而且增加產品編譯時間。還有，當你必須更改產生UUID機制，你 必須修正兩個地方，使程式碼缺少一致性。 因此，建議篩選Boost函式