c++ - 关于包装第三方库的建议

Question

我作为软件开发人员在一家公司的计算机视觉部门工作了一年。我的主要工作是将第三方软件集成到框架中，所以我通常最终会编写包装器库，因为很多第三方软件无法按照我们希望的方式工作(不是线程安全的，a * 的痛苦* 使用等)。

通常我只是包装整个库并使用互斥来保护对库的调用(线程安全在某种程度上是大多数外部库的主要问题)。我真的很喜欢这样做，因为它会让你置身于许多有趣的情境中，并且你会看到很多有趣的代码。但是我经常认为我做得不正确或者我的实现不是很好。我觉得我缺乏关于如何正确地做这样的事情的某种设计知识。

基本上，我想知道是否有关于设计适当的“在损坏的 API 之上的 API”的任何好的指导方针或提示，或者这是否总是非常骇人听闻和丑陋。

Answer 1

前几天我会在这里引用另一个问题的答案:

1. 您当前的方法是否通过测试？
2. 速度够快吗？

如果是，请继续做您正在做的事情。

作为替代方案

只需确保您的新 API 包含原始 API 的预期功能和常规或意外功能。还要确保它呈现出“适合用途”的再现。看一看 FOSS 项目中 C 库的 C++ 包装，例如 GTK/GTK for C++(仅包装前者)。

如果 API 损坏，请修复它并提交补丁...与第三方合作(我假设可以访问源代码意味着他们不会介意)...您可以重写他们的一些 API 是“包装友好”的，并建议他们合并一些更改。如果有问题，请成为解决问题的人。

没什么大不了的，只需用 B 包裹 A 并确保 B 执行 A 应该做的或用于 A 的事情。