為什么我應該用c ++而不是c來設置插件接口

Question

由於我之前的 問題，我問自己：為插件系統設置C ++接口是否有用？ 以下幾點是針對它的：

• 不同編譯器及其版本之間沒有共同的ABI，內存中沒有對象的共同布局
• 沒有直接的班級出口。 你必須出口工廠和析構工具。 如果您的對象由僅delete它們的其他對象（例如智能指針）保留，則會出現問題。
• STL的不同實現，你不能將std::list<T>傳遞給插件
• 不同版本的二手庫，如Boost

如果你克制自己的C ++語言的其余部分，你幾乎最終得到“C子集”。 有沒有關於使用C ++的觀點？ Qt-Toolkit如何解決上述問題？

備注：我主要指的是Linux系統。 不過我對其他平台上的解決方案感興趣。

其他問題：使用C接口有什么問題？ struct s的內存布局？ 應該避免C的哪些語言部分？

Answer 1

雖然這更像是關於“如何”而不是“為什么”，但您可能對（尚未）Boost.Extension庫以及作者關於該主題的博客感興趣。

對於“為什么”部分，我的2（加拿大）美分：它取決於受眾（插件編寫者）以及應用程序與其插件之間的接口豐富程度：

• 如果受眾是大型或異構的，C ++插件系統的局限性（保持插件端和應用程序端與編譯器和庫版本同步）變得不切實際，並且C接口更易於維護。 如果觀眾很小，同質或受你的控制，這些問題就不那么重要了。
• 如果界面很豐富（在“富”的精確含義上揮手），C接口可能會變得很麻煩，並且平衡在C ++端傾斜。

然而，第一個標准（觀眾）更為重要，因此只有當觀眾是同質的並且界面顯着受益於表達性收益時，C ++界面才有意義。

Answer 2

我曾經用C ++制作了我開發的系統的插件接口，這是一個很大的錯誤。 可行，但根本不實用。 今天，我總是把界面純粹用C語言制作，盡可能簡單。 這些選擇的好處非常重要。 如果你的插件編寫者想要一個C ++ API，你可以簡單地編寫一個調用C接口的C ++包裝器。

另外一個好處是，如果您的插件編寫者需要任何其他語言的API，那么C API將始終更容易創建綁定。

Answer 3

通常，將接口編寫為可以依賴的某些接口標准是一個明智的想法。 這就是為什么幾乎每個操作系統都提供這樣的界面。 在大多數Unix上，C編譯器使用與OS相同的約定，因此將它們稱為C調用約定。 Windows已為此目的進行了調用。

如果你嘗試使用一些編譯器內部調用接口，比如C ++，那么你將成為你提到的所有問題的犧牲品。 即使編譯器更新也容易讓您感到困惑。

Answer 4

我想你在那里回答你自己的問題。 沒有什么可以阻止你實現一個簡單的C插件接口，並允許插件編寫者用C ++實現他們的插件。 只是嘗試從Netscape Plugin API的錯誤中吸取教訓......