静态库 API 问题（std::string 与 char*）
我以前没有使用过静态库，但现在我需要。
场景：
我正在 Unix 中编写一个控制台应用程序。我在任何地方自由地使用 std::string 因为这样做很容易。然而，我最近发现我必须在 Windows 中支持它，并且第三方应用程序需要 API 来连接我的代码（我不会共享源代码，仅共享 DLL）。
考虑到这一点，我是否仍然可以在代码中的任何地方使用 std::string ，但在编写 API 时为它们提供 char * ？那行得通吗？
I have not worked with static libraries before, but now I need to.
Scenario:
I am writing a console app in Unix. I freely use std::string everywhere because it's easy to do so. However, I recently found out that I have to support it in Windows and a third party application would need API's to my code (I will not be sharing source, just the DLL).
With this in mind, can I still use std::string everywhere in my code but then provide them with char * when I code the API's? Would that work?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
是的。在内部使用
std::string，然后在接口函数上使用const char *（这将被转换为std::string输入。Yep. Use
std::stringinternally and then just useconst char *on the interface functions (which will be converted tostd::strings on input.为什么不直接为他们提供 std::string ？
它是标准的 C++，如果他们不支持它，我会感到非常惊讶。
Why not just provide them with std::string?
It's standard C++, and I'd be very suprised if they didn't support it.
问题是，您的客户将使用该指针做什么。它当然应该是 const char* ，但是如果客户端稍后保留并引用它，那么在内部使用 std::string 可能会有风险，因为一旦您自己对字符串进行操作，就会有无法阻止 std::string 移动内存，因为它的引用计数机制无法与导出的 char* 指针一起使用。只要您不触摸 std::string 对象，它们的内存就不会移动，并且指针是安全的。
The question is, what your clients will do with that pointer. It should of course be
const char*, but if clients will keep and reference it later on, its probably risky to use std::string internally, because as soon as you operate yourself on the strings there is no way to keep std::string from moving memory, as its reference counting mechanism can not work with exported char* pointers. As long as you dont touch the std::string objects, their memory wont move, and the pointer is safe.没有标准化的 C++ 二进制接口（至少我还没有听说过），因此具有不同设置的项目可能看起来无法链接在一起。例如，Visual C++ 提供了一种启用/禁用迭代器调试支持的方法。这是由宏控制的，某些数据结构的大小取决于它。
如果使用不同设置编译的两个代码开始使用这些数据结构进行通信，那么最好的结果就是链接器错误。其他替代方案更糟糕 - 稳定的运行时错误、仅发布配置错误等...
因此，如果您不想将用户限制为单个正确的项目设置集和编译器版本，请仅使用接口的原始数据。对于内部实施，选择更方便的。
There is no standardized C++ binary interface (at least I haven;t heard about it), thus projects with different settings may appear to be unlinkable together. For example, Visual C++ provides a way to enable/disable iterator debug support. This is controlled by macro and size of some data structures depends on it.
If two codes compiled with different settings start to communicate using these data structures, the best thing you can have is linker error. Other alternatives are worse - stable run-time error, release-configuration-only error, etc...
So if you don't want to restrict your users to single correct project settings set and compiler version, use only primitive data for interface. For internal implementation choose what is more convenient.
添加到 Poita_ 的响应：
考虑 unicode 支持
如果您也需要支持本地化，您会很高兴首先做到这一点
或者，您可以返回一个必须通过库导出的方法释放的副本。 （C++ 客户端可以将其移至智能指针以重新获得自动内存管理。）
Adding to Poita_'s response:
consider unicode support
If you ever have to support localization, too, you'll be happy to have done it in the first place
when returning char/wchar_t const *, define the lifetime of the data. The best would be to have a project-wide "unless stated otherwise..." standard
Alternatively, you can return a copy that must be freed through a method exported by your library. (C++ clients can move that into a smart pointer to regain automatic memory management.)
std::string 至少可以在 Visual Studio C++（和其他）中工作，那么为什么不直接使用它呢？
std::string will work in, at the very least, Visual Studio C++ (and others), so why not just use that?