2

这是对上一个问题的跟进。

我正在开发一个库，客户需要为其提供复杂的类型，如矩阵和四元数。在内部，我将使用Eigen来操作这些类型，并且根据链接问题中的讨论，我可能会对 Eigen 的类型进行一个薄包装，并要求客户将这些类型提供给我的库，本质上将 Eigen 隐藏为内部实现细节。

事实上，由于我的一些客户可能已经在使用 Eigen，所以有人建议我在我的 Eigen 类型的包装版本中提供某种类型的 to/from Eigen 函数。

这一切听起来都很好，但我担心如果我的库在内部使用与我的客户使用的不同版本的 Eigen 可能会发生什么。如果这两个版本兼容 ABI，那么我认为没有任何问题。但是，如果它们不是，那么我可以想象一些“坏”的事情正在发生。我特别担心，因为 Eigen 是一个仅限标头的库，我不能假设，例如，我的库和我的客户端都将链接到第三方库的相同编译版本。

如果我为我的用户提供源代码并让他们自己根据 Eigen 进行编译，那么我就不必太担心了。但是，我最关心的是为我的用户编译和安装 DSO/DLL 的情况。

所以，我想我的问题是：我是否必须限制我的客户使用与 ABI 兼容的库版本？我可以为 Eigen 提供必要的标题，但是用户已经在使用 Eigen 会有问题。

我想我可以让我的客户对我的包装器类型进行必要的转换，但我想提供方便的功能。

请注意，虽然我特别在谈论 Eigen，但这个问题可能适用于任何提供类型的第三方库。

谢谢！

4

1 回答 1

2

提供您自己的类型绝对是最通用的方法，并确保人们可以在没有第三方库（即 Eigen）的情况下使用您的库。由于您永远不能希望涵盖您的客户可能使用的所有可能的第三方库，因此我建议将转换功能留给您的最终用户/实施者。

如果提供转换/便利功能非常重要，那么只需在单独的源文件中实现它们并直接提供给您的客户；一点糖衣，向他们表达你的关心。

顺便说一句，我认为您总是希望在可用的情况下使用“标准”结构。我知道 STL 没有“矩阵”或“四元数”数据类型，但 Boost有，而且Boost几乎与您可以达到的标准一样接近，而实际上却不符合标准。因此，这为您提供了另一种可能性。

于 2012-05-14T19:25:08.873 回答