namespace 啊。

【 在 xieyf ( meitian ) 的大作中提到: 】
: 一个很大的c++库, 有很多对象, 现在需要操作这些对象, 需要搞出一些公共的API来,
: 比如createXXObject, destroyXXObject这种, 这些api一般是写成对象的静态函数, 还是
: 直接写成C API? 还是写一个专用的global 静态类?
: ...................
--
FROM 110.81.41.*

定好一个规则随便写就是了
namespace 和static member func在编译器眼里都是一样

static member func可以强制带上限定名，相对严格一点，看上去逼格高一些
【 在 xieyf 的大作中提到: 】
: namespace自然是有.
:
:
--
FROM 119.103.122.*

COM is the best choice I think.

【 在 xieyf 的大作中提到: 】
: 一个很大的c++库, 有很多对象, 现在需要操作这些对象, 需要搞出一些公共的API来,
: 比如createXXObject, destroyXXObject这种, 这些api一般是写成对象的静态函数, 还是
: 直接写成C API? 还是写一个专用的global 静态类?
: ...................
--
FROM 221.219.186.*

对象之间有关系，首先考虑facade，封装成一个或几个接口供客户用。这样内部复杂，使用简单。

对象之间无关系，像Opencv那样的松散算法类，不提供全局对象，客户自己创建吧。我见过图形库（引擎）为了调优，内部有全局的缓存的，但并没说明。后来提了bug，也没改，只在接口上说明不支持多线程。

导出给Main.exe使用，另一个帖子里问dlopen那种，我见过的，
是Main有决定权，所以定义了IPluginInterface，规定了纯虚接口。
plugin.dll实现一个MyPlugin类，再提供一个C接口GetInstance（Main通过文档约定）。Main用时，直接调用这个接口，得到实例，不考虑释放。
这样设计就是所谓的“依赖反转”。

Main没有决定权，按照设计原则，应该是加一层封装，把第三方Plugin封装一层。
Main就又有了决定权，定义个接口约束适配层。
【 在 xieyf 的大作中提到: 】
: 一个很大的c++库, 有很多对象, 现在需要操作这些对象, 需要搞出一些公共的API来,
: 比如createXXObject, destroyXXObject这种, 这些api一般是写成对象的静态函数, 还是
: 直接写成C API? 还是写一个专用的global 静态类?
: ...................
--
FROM 36.46.5.*

说到C++库的C API，我觉得LLVM封装过的C API用起来还是很方便的。

【 在 here080 (hero080) 的大作中提到: 】
: C++的库正常肯定不写成C API
: 至于用什么模式，取决于你的库的具体情况和内容。
: 不能为了模式而模式。
: ...................
--
FROM 103.90.178.*