静态库API问题（std :: string vs. char *）

Question

之前我没有使用静态库，但现在我需要。

情境：

我正在用Unix编写一个控制台应用程序。我随处可以使用std::string，因为这很容易。但是，我最近发现我必须在Windows中支持它，第三方应用程序需要我的代码的API（我不会共享源代码，只是DLL）。

考虑到这一点，我是否仍然可以在代码中的任何地方使用std::string，但在编写API代码时，我们会为其提供char *？那会有用吗？

Answer 1

是的。在内部使用std::string，然后在接口函数上使用const char *（在输入时将转换为std::string。

Answer 2

为什么不直接为他们提供std :: string？
它是标准的C ++，如果他们不支持它，我会非常惊讶。

Answer 3

问题是，您的客户将使用该指针做什么。它当然应该是const char*，但是如果客户端稍后会保留并引用它，那么在内部使用std :: string可能会有风险，因为只要你自己操作字符串就没有办法保持std ::来自移动内存的字符串，因为它的引用计数机制不能与导出的char *指针一起使用。只要你不接触std :: string对象，它们的内存就不会移动，并且指针是安全的。

Answer 4

没有标准化的C ++二进制接口（至少我没有听说过），因此具有不同设置的项目可能看起来是不可链接的。例如，Visual C ++提供了一种启用/禁用迭代器调试支持的方法。这是由宏控制的，一些数据结构的大小取决于它。

如果使用不同设置编译的两个代码开始使用这些数据结构进行通信，那么您可以拥有的最好的是链接器错误。其他替代方案更糟糕 - 稳定的运行时错误，仅发布配置错误等......

因此，如果您不希望将用户限制为单个正确的项目设置集和编译器版本，请仅使用原始数据作为接口。对于内部实现，选择更方便的。

Answer 5

添加Poita_的回复：

• 考虑unicode支持 如果你也必须支持本地化，你会很乐意在第一时间完成它

• 返回char / wchar_t const *时，定义数据的生命周期。最好的是在项目范围内“除非另有说明......”标准 或者，您可以返回必须通过库导出的方法释放的副本。 （C ++客户端可以将其移动到智能指针中以重新获得自动内存管理。）

Answer 6

std :: string至少可以使用Visual Studio C ++（以及其他版本），为什么不使用它呢？