旧版 Win32 DLL 中的空终止字符串 C++ - 有没有更好的方法

Null terminated strings in a legacy C++ Win32 DLL - is there a better way?

本文关键字：C++ 有没有方法更好字符串终止 Win32 DLL 旧版更新时间：2023-10-16

在十多年没有

在 C++ 中编程之后，我正在尝试将正确的错误报告添加到旧版 Win32 DLL C++。

这有力地提醒了在 C/C++ 中使用以 null 结尾的字符串令人难以置信的乏味 - 更不用说潜在的缓冲区溢出和安全问题了。

我正在考虑使用更高级的字符串库 - 也许是 MFC CString 或 STL 库。

编辑

DLL被我们软件的旧版本（用C++编写）和新版本（用C#编写）使用。

编译器是VS2008。

对于第一次传递，我将登录到标准 Windows 事件日志，因为将错误消息传递回 DLL 客户端将是一个很大的体系结构更改（当前体系结构很糟糕，多个故障模式被折叠为单个布尔通过/失败返回值，该值一直传递回调用堆栈。不用说，这使得问题诊断成为一场噩梦）。但是我想在以后的某个时候改进这一点。

字符串库问题

由于这是一个 DLL，这甚至是一个好主意吗？

DLL 是否有任何特殊注意事项？

我应该注意的陷阱？

为此目的，一个库比另一个库更好吗？

空字符串问题

如果我遇到以 null 结尾的问题，我应该使用哪组字符串函数？ MS 帮助文档不鼓励使用旧的 C 函数（例如 strcat 等）。但是现在似乎还有许多其他选项可用（例如_tcscat，_mbscat，wcscat等）。我应该使用哪个，为什么？

从 DLL 共享任何类型的模板类都是危险的。由于模板位于头文件中，因此您无法控制程序是否使用与 DLL 相同的标头版本 - 不匹配可能会导致致命的错误。

至于 _tcscat、_mbscat 和 wcscat 之间的差异，您需要确定 API 的字符集。_mb函数使用大多数过时的多字节字符集，wc函数使用wchar_t Unicode。_t函数将解析为一个或另一个，具体取决于您设置项目定义的方式。

这实际上取决于您要添加的错误报告类型，以及该报告是仅在 DLL 内部还是越过 DLLL 边界进入调用 EXE。您可以在 DLL 的内部代码中使用所需的任何字符串类/库，但对于导出的 DLL 函数和回调的参数，应继续使用 null 结尾的字符指针，以便与多个编译器和语言兼容。

如果你小心的话，你总是可以使用std::string构造函数转换任何传入的内容，并使用str.c_str()转换任何传出的东西。