对于如何包装内部库以将其交付给客户,您有什么建议吗?

在我的公司,我们使用一个跨平台的实用程序库,提供很多服务。

这包括跨平台代码(例如,包装win32或pthread api的线程类)或每个公司特定的代码(例如,处理服务器和客户机应用程序之间专有通信协议的类)。

我们需要将这些功能的一部分交付给客户机,客户机同意使用与库相同的编译器和编译器选项。

目前,我的设计的中心是确保我们的库的每个版本的接口都与以前的版本二进制兼容:

1. 传递dll/so库
2. 使用简单明了的命名约定(受Java CAMELCANMENM等启发)
3. STL的使用
4. 使用全局命名空间(并为具有非二义性名称的任何宏添加前缀,以避免名称冲突)
5. 对需要使用的每个类进行pimpl-ing
6. 做每件事(把“公共部分”交给客户)
7. 简化和统一我们的界面
8. PIMPL类中没有虚拟方法
9. 没有内联代码,除非出现异常(甚至常量都是导出的常量值,在编译源中定义,并且只在公共头中声明)
10. 实用程序/间接函数的异常内联代码,内部没有太多代码(例如,交换函数将是内联的,调用它交换的对象的非内联交换方法)
11. 一些简单的“值类”的异常内联代码,没有真正的代码,以避免不必要的开销(例如,复杂的数字类将被内联)
12. 通过内联代码提供高级服务(调用关于的pimpl-ed类)(意味着客户机可以根据自己的需要重用/修改它)

我的列表是否完整,或者我是否遗漏了一些可以简化未来维护/改进的内容?

我的观点之一是错误的吗?