第三方类型是否应该在我的C++库的API中公开

pla*_*sma 5 c++ api

我正在开发一个C++库,用户将提供复杂的输入,例如矩阵和四元数.我不想重新实现这些类型,因此,在内部,我将使用Eigen库.

我正在尝试确定将这些类型公开给我的库客户端的最佳方法,并为我的API提供了一些选项.我使用四元数类型作为示例,但这可以同样适用于矩阵等.此外,虽然我特别谈到暴露Eigen的类型,但我想这个问题同样适用于其他使用的外部库.

1)仅使用基本的C++类型

此选项将要求客户端通过基本类型传递数据.例如,对于传入四元数(4个元素),可以执行以下操作:

void my_func(double my_quat[4])
Run Code Online (Sandbox Code Playgroud)

2)暴露本征的类型

Eigen为数组和四元数提供了几种模板化类型.例如,如果一个函数需要一个四元数,我可以使用Eigen的Quaterniond 类型(它实际上是一个typedef Quaternion<double>):

void my_func(const Eigen::Quaterniond& my_quat)
Run Code Online (Sandbox Code Playgroud)

3)为客户端的各种类型创建一个简单的包装器

我可以创建一个非常简单的四元数类型(比方说,某种简单的结构),客户端必须创建(可能通过某种工厂函数)传递给我的API:

void my_func(const quaternion_t& my_quat)
Run Code Online (Sandbox Code Playgroud)

我的库会将quaternion_t类型转换为我的内部特征表示.

我不太喜欢选项1,因为我希望在我的API中有更强的输入感.选项2将要求我的客户也使用Eigen,更不用说他们使用不同版本的Eigen时兼容性的潜在问题(顺便说一下,如果重要的话,Eigen是一个只有头的库).这留下了选项3.

人们怎么想?我基本上回答了自己的问题吗?有什么例子吗?

相关问题

这里提出一个相关的问题,但没有详细说明是否应该公开外部类型.

dje*_*lin 2

包裹/封装。假设您想添加一些附加功能,例如缓存计算结果(例如四元数的范数)作为实现更改。如果您公开第 3 方类型而不强制客户端代码更改其调用,则您将无法(轻松)做到这一点。