使用std :: function（跨越模塊邊界）

很確定我知道這個答案（思考否），但是可以安全地接受/返回std :: function在API中的值（跨模塊邊界）？使用std :: function（跨越模塊邊界）

我想'不'，因爲我不認爲有任何保證，一個供應商的std :: function實現與另一個兼容。是這樣嗎？

如果答案不是我所懷疑的，那麼你們怎麼處理這種事情呢？我可能不得不求助於實現我自己的或者只是一起避免諸如std :: function之類的東西（例如：使用函數指針或函數）。 :-(在許多情況下，我發現自己在這麼做的時候（重新創建了很多標準的C++庫，並且很遺憾甚至製作了我們自己的兼容STL的矢量類型，同時支持範圍ctor和fill ctor，自定義分配器等等。當然，這並不好玩，我懷疑它和標準實現一樣好），只是因爲人們可能會動態鏈接到一個庫，例如MSVC 2010使用mingw編寫的二進制文件實現std :: function，例如

當然，替代方案是在我們的API中不使用這些類型的C++特性，並且使用C接口，但這對我們來說代價相當昂貴，因爲我們使用我們的API作爲中央API內部和第三方開發

來源

2012-02-26 stinky472

這與*任何*編譯的C++庫面臨的問題相同...... – 2012-02-26 21:02:14

@KerrekSB：不是靜態庫。只是試圖跨DLL邊界使用標準庫類型的DLL。它不是用C類型保存的（比如'FILE *'），但是你通常不會看到人們想要通過DLL來拋出它們。 – 2012-02-26 21:05:12

似乎是這樣。我總是想知道人們如何處理它（例如：如果有一些交叉編譯器的選擇，我們可以使用這些替代方法，可以跨模塊邊界工作，比如說，通過我們的SDK分發源代碼）。總是希望有更多的關注跨越模塊邊界使用C++，因爲我們通過在DLL /共享庫中實現的API來集中開發，像std :: function這樣的東西在常規回調函數或函數中非常有用，尤其是在添加lambda表達式。 – stinky472 2012-02-26 21:06:21

你可以做到這一點，只要e一個人玩的是相同的規則，而你的標準庫是動態鏈接的。如果第三方知道他們必須使用特定的編譯器，以及該編譯器的特定版本以及某些特定的構建標誌，那麼這是沒有問題的。

即使你編寫自己的包裝器，他們也必須使用該包裝器的特定版本，儘管顯然這更容易實施。

但實際上，這是您嘗試通過DLL進行互操作所付出的代價：每個人都必須位於同一頁面上，否則它將無法工作。或者你必須堅持使用基本類型或本土控制的界面。

來源

2012-02-26 21:04:11

我明白了，謝謝。本土解決方案就是我們一直在做的事情，但複製一些基本標準庫類型的用處變得非常痛苦，例如vector，wstring，unique_ptr，shared_ptr，function等等，這些都可以很好用用於構建公共接口。如果沒有人已經這樣做，我幾乎可以開始一個開源，簡約，交叉編譯的解決方案。我們正在考慮提高效率，但這樣做也有點棘手，因爲boost非常巨大，開發人員可能希望使用比我們發佈的版本更新的版本。 – stinky472 2012-02-26 21:10:06

提升怎麼樣？ – ronag 2012-02-26 21:13:12

增強是我們考慮發佈的內容，但它有點困難，因爲它太大了，我們經常想知道如果第三方已經在使用與我們分發的版本不同的版本會發生什麼。這會使我們的SDK比它大很多倍，並且使用它的某些部分有點困難，因爲許多功能都是從其他部分構建的。也許我們應該再看一遍，因爲在這種情況下boost :: function會很好地工作，並且支持許多不同的編譯器當然是非常好的。 – stinky472 2012-02-26 21:15:23

使用std :: function（跨越模塊邊界）

回答

相關問題