作爲C++庫API的一部分的第三方類型和潛在的ABI不一致性

Question

這是前一個question的後續行爲。

我正在開發一個庫，客戶需要提供類似矩陣和四元數的複雜類型。在內部，我將使用Eigen來操縱這些類型，並且根據鏈接問題的討論，我可能會在Eigen的類型上放一個簡單的包裝，並要求客戶將這些類型提供給我的庫，實質上隱藏了Eigen作爲內部實現細節。

因爲我的一些客戶實際上可能已經在使用Eigen，所以我建議我在Eigen類型的包裝版本中提供某種到/從Eigen功能。

這一切聽起來都不錯，但我擔心如果我的圖書館在內部使用不同於我的客戶使用的Eigen版本會發生什麼情況。如果這兩個版本是ABI兼容的，那麼我沒有看到任何問題。但是，如果他們不是，那麼我可以想象一些「壞」的事情發生。我特別擔心，因爲Eigen是一個僅包含頭文件的庫，我不能認爲，例如，我的庫和我的客戶端都將鏈接到第三方庫的相同編譯版本。

如果我向我的用戶提供源代碼並讓他們自己編譯來對抗Eigen，那麼我不必擔心太多。不過，我最關心的是爲我的用戶編譯和安裝DSO/DLL的情況。

所以，我想我的問題是：我必須限制我的客戶使用ABI兼容版本的庫？我可以爲Eigen提供必要的標題，但用戶已經使用Eigen會有問題。

我想我可以把它留給我的客戶做必要的轉換到我的包裝類型，但我想提供便利功能。

請注意，雖然我特別談論特徵，但這個問題可能適用於任何提供類型的第三方庫。

謝謝！

Answer 1

提供您自己的類型絕對是最普遍的方法，並確保人們可以在沒有第三方庫（即Eigen）的情況下使用您的圖書館。既然你永遠不可能希望覆蓋你的客戶端可能使用的所有可能的第三方庫，我建議將轉換功能留給最終用戶/實施者。

如果提供轉換/便利功能非常重要，那麼只需將它們實施在單獨的源文件中並直接提供給客戶;一點點糖塗層，以顯示你的照顧。

順便說一句，我認爲你總是希望在可用的地方使用「標準」結構。我知道STL沒有「Matrix」或「Quaternion」數據類型，但Boost 確實是，並且Boost與您在達到標準時差不多，但實際上並沒有達到標準。所以這爲你提供了更多的可能性。