【发布时间】：2016-11-30 11:45:25
【问题描述】：
我开始为用 C++ 编写的 Windows 桌面开发一个全新的项目。当我学习 Windows 编程时，我读到使用 TCHAR 是一个很大的改进，因为我可以在不更改代码的情况下构建我的程序的 ANSI 或 Unicode 版本。但是，我从未真正使用过该选项来构建 ANSI 版本。此外，在 C++ 的标准库中，没有 TCHAR，我必须为 std::string、std::stringstream 等及其宽字符串对应物创建 typedef。所以目前我正在考虑放弃TCHAR转而使用wchar_t，我收集了以下优点和缺点。
优点：
- TCHAR 是一个宏，所以如果我不使用它，前端编译器和 Intellisense 会给出更好的结果。
- 变量的类型更明确。
- L"" 比 _T("") 更容易输入。
缺点：
- 缺少关于字符类型的模块化（即使我并不真正需要 ANSI 版本，但我发现使用抽象字符类型是一个很好的功能，如果将来我需要 UTF-8 或UTF-32 版本？）。
- 我必须用 W 对一些 API 函数进行后缀，例如 GetWindowTextW。
还有我的问题：
- 在 C++ 标准库中是否有比我上面描述的更简单的方法来使用 TCHAR？像具有这些 typedef 的标准头文件一样？
- 你认为我的推理正确吗？
- 我是否遗漏了什么重要的一点？
- 当今最先进的解决方案是什么？专业的 Windows 程序员是否仍在使用 TCHAR（在新代码中）？
- 如果我删除 TCHAR，我应该写 L"" 或 u"" 而不是 _T("")？
【问题讨论】：
-
感谢链接，我也找到了，但我的问题有点不同，无论如何我不认为 2008 年的答案可以被自动接受为 state-of-the - 2016 年的艺术解决方案。
-
IMO 不值得付出额外的努力，坚持一个并在适当的时候进行转换。如果 TCHAR 能够完美实施，那将是另一回事，但事实并非如此。在我们公司，我们坚持使用 std::string 并使用 UTF-8 字符串，它工作得很好，当我们需要处理 Win32 时，我们转换为 wchar_t
-
YAGNI - 如果 Windows 突然支持 UTF-8 或 UTF-32，那么您的 TCHAR 代码会为此工作有什么奇怪的。大约为零。而且您没有必须在系统调用中添加 W，windows.h 包含为您执行此操作的宏。
-
这是一个基于意见的问题，因此应该关闭。答案是，如果您计划以 Windows 98 为目标，您应该使用
TCHAR。如果没有，那么您应该使用TCHAR。希望您将来可以免费获得 UTF-8 支持是一厢情愿的想法。 Windows 永远不会通过与 ANSI 和 Unicode 相同的 A/W 机制来支持 UTF-8。