与遗留 TCHAR 代码交互的正确样式

发布于 2024-09-09 00:36:29 字数 763 浏览 11 评论 0原文

我正在修改广泛使用 TCHAR 的其他人的代码。在我的代码中使用 std::wstring 是更好的形式吗? wstring 应该等同于 Widechar 平台上的 TString,所以我没有看到问题。基本原理是,使用原始 wstring 比支持 TCHAR 更容易......例如,使用 boost:wformat。

下一个维护者会更清楚哪种风格?我自己浪费了几个小时试图理解字符串的复杂性,似乎仅仅使用 wstring 就会切断你需要理解的一半内容。

typedef std::basic_string<TCHAR> TString; //on winxp, TCHAR resolves to wchar_t
typedef basic_string<wchar_t, char_traits<wchar_t>, allocator<wchar_t> > wstring;

...唯一的区别是分配器。

在不太可能的情况下,您的程序 登陆到 Window 9x 机器上,有 仍然是一个可以翻译的API层 将 UTF-16 字符串转换为 8 位字符。 使用 TCHAR 没有任何意义 用于新代码开发。 来源

I'm modifying someone else's code which uses TCHAR extensively. Is it better form to just use std::wstring in my code? wstring should be equivalent to TString on widechar platforms so I don't see an issue. The rationale being, its easier to use a raw wstring than to support TCHAR... e.g., using boost:wformat.

Which style will be more clear to the next maintainer? I wasted several hours myself trying to understand string intricacies, it seems just using wstring would cut off half of the stuff you need to understand.

typedef std::basic_string<TCHAR> TString; //on winxp, TCHAR resolves to wchar_t
typedef basic_string<wchar_t, char_traits<wchar_t>, allocator<wchar_t> > wstring;

...the only difference is the allocator.

In the unlikely case that your program
lands on a Window 9x machine, there's
still an API layer that can translate
your UTF-16 strings to 8-bit chars.
There's no point left in using TCHAR
for new code development.
source

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

遥远的绿洲 2024-09-16 00:36:29

如果您只想针对 Unicode (wchar_t) 平台,那么最好使用 std::wstring。如果你想支持多字节和 Unicode 构建,你将需要使用 TString 和类似的。

另请注意,basic_string 根据传入的字符类型将 char_traits 和分配器默认为 1,因此在 UNICODE(或 _UNICODE,我永远不记得是哪个)的构建中,TString 和 wstring 将是相同的。

注意:如果您只是将参数传递给各种 API,而不对它们进行任何操作,那么最好使用 const wchar_t * 而不是直接使用 std::wstring (特别是如果混合使用 Win32、COM 和标准 C++ 代码),因为您最终将减少转换和复制。

If you are only intending on targetting Unicode (wchar_t) platforms, you are better off using std::wstring. If you want to support multibyte and Unicode builds, you will need to use TString and similar.

Also note that basic_string defaults the char_traits and allocator to one based on the passed in character type, so on builds where UNICODE (or _UNICODE, I can never remember which), TString and wstring will be the same.

NOTE: If you are just passing the arguments to various APIs and not doing any manipulations on them, you are better off using const wchar_t * instead of std::wstring directly (especially if mixing Win32, COM and standard C++ code) as you will end up doing less conversions and copying.

离线来电— 2024-09-16 00:36:29

当您要编译二进制文件两次(一次针对 char,第二次针对 wchar_t)时,TCHAR 曾经更为重要。

如果您愿意,您仍然可以做出此选择,将 MSVC 项目设置从 MBCS 更改为 Unicode,然后再更改回来。

这也意味着在调用 Windows API 时您将拥有匹配的数据类型。

TCHAR used to be more important when you where going to compile the binaries twice, once for char and a second for wchar_t.

You can still make this choice if you like, changing the MSVC project settings from MBCS to Unicode and back.

This also means when calling the windows API you will have the matching data type.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文