不要在公共介面中傳遞STL容器

2021-08-19 21:19:00 字數 623 閱讀 7991

最近的乙個專案,是開發乙個framework,提供給公司內部不同的產品線使用。 之間遇到的乙個問題,就是stl容器的使用, 而結論是不要在公共介面中傳遞stl容器:

也可以說,不要在暴露給客戶的標頭檔案中包含stl的標頭檔案。

為什麼有這個結論,我們可以從幾個方面來論述:

雖然,微軟這篇文章提到匯出vector是安全的,但這應該是有風險的:

除非能夠確信你的dll和dll的使用者會使用完全相同的stl - 版本一致,編譯選項一致,沒有被自定義過等,不然就可能導致行為的不一致性:

舉個例子,你在dll中匯出了vector,而這個dll的客戶使用的stl是自定義的版本,記憶體管理由其自己實現,那麼vector在客戶方就可能有了兩種含義。

但事實上,你還是可能存在這種需求的 - 你需要容器類的函式引數或者返回值,你可能也需要容器類的類成員變數,那麼如何解決? 

對於前者,我們可以針對具體的型別封裝乙個具體的容器類,內部還是可以使用stl container的;

對於後者,我們可以用一些辦法,防止stl容器出現在標頭檔案中; 

解決的方法,可以有以下幾種:

所以,結論就是不要在dll/so的公共介面中使用stl容器,如果你確實需要,那麼請用自定義結構體封裝容器並前置宣告的方式隔離stl容器!

不要在介面定義中使用 TCHAR 字串

本文 李馬 http blog.titilima.com show 568 1.html 其實在我最初的構想中,這個對話方塊的提示文字並不是系統預設的文字,而應該是我寫上去的 最起碼把 windows 替換成 july 但是我最後放棄了,因為我寫上去的字到最後顯示出來是亂碼。由於 runfiledl...

不要在介面定義中使用 TCHAR 字串

先上個圖,july 早期版本的 執行 對話方塊。其實在我最初的構想中,這個對話方塊的提示文字並不是系統預設的文字,而應該是我寫上去的 最起碼把 windows 替換成 july 但是我最後放棄了,因為我寫上去的字到最後顯示出來是亂碼。由於 runfiledlg 這個 api 並沒有詳細的文件支援,而...

做LFS,千萬不要在window系統中複製配置檔案

作者 馮牮 fengjian0106 yahoo.com.cn 很早就看過lfs這本書,對學習linux很有幫助,但是一直都沒有動手編譯一遍,上周末,終於動手做了,斷斷續續折騰了兩天,結果啟動的時候出現如下錯誤 init etc inittab 2 missing action field init...