这是对之前question的跟进。
我正在开发一个库,客户端需要提供像矩阵和四元数这样的复杂类型。在内部,我将使用Eigen来操作这些类型,并且基于链接问题中的讨论,我可能会在Eigen的类型周围放一个薄的包装,并要求客户端将这些类型提供给我的库,基本上隐藏Eigen作为内部实现细节。
由于我的一些客户实际上可能已经在使用Eigen,所以我建议在我的Eigen类型的包装版本中提供某种特征函数。
一切听起来不错,但是我担心如果我的库在内部使用不同版本的Eigen而不是我的客户使用的话会发生什么。如果两个版本兼容ABI,那么我没有看到任何问题。但是,如果他们不是,那么我可以想象一些“坏”的事情正在发生。我特别担心,因为Eigen是一个仅限标题的库,我不能假设,例如,我的库和我的客户端都将链接到第三方库的相同编译版本。
如果我向我的用户提供源代码并让他们自己编译反对Eigen,那么我就不用太担心了。但是,我最关心的是我为用户编译和安装DSO / DLL的情况。
所以,我想我的问题是:我是否必须限制我的客户使用ABI兼容版本的库?我可以为Eigen提供必要的标题,但是用户已经使用Eigen会有问题。
我想我可以将它留给我的客户进行必要的转换到我的包装类型,但我想提供便利功能。
请注意,虽然我特别谈论Eigen,但这个问题可能适用于任何提供类型的第三方库。
谢谢!
答案 0 :(得分:2)
提供您自己的类型绝对是最普遍的方法,并确保人们可以使用您的库与OR而不使用第三方库(即Eigen)。由于您永远不能希望涵盖客户可能使用的所有可能的第三方库,我建议将转换功能留给最终用户/实施者。
如果提供转换/便利功能非常重要,那么只需在单独的源文件中实现它们并直接提供给客户;一点糖涂层,以表明你的关心。
顺便说一句,我认为你总是希望在可用的地方使用“标准”结构。我知道STL没有“矩阵”或“四元数”数据类型,但是Boost 确实,而Boost与您可以达到标准的距离非常接近,而实际上并不在标准。所以这为你提供了另一种可能性。