虽然wchar_t在支持不同编译器的情况下不一致，但假设wchar_t至少在 Linux 上的 GNU/GCC 中的实现和大小相似是否安全？
尽管wchar_t大小在位大小（32 位/64 位）方面具有系统架构依赖性，但 Linux 上的宽字符类型（GNU/GCC）实际上是依赖于编译器还是依赖于 libstdc++ 库？我的意思是更改或升级哪个我应该考虑的wchar_t可能在大小和支持方面可能无法按预期工作
虽然IBM ICU 是另一种选择，但它可以与std::string?
我应该完全驳回wchar_tICU吗？
注意：在类似 Unix 的操作系统上，例如带有 GNU/GCC libstdc++ 的 Linux，为编译器带来了核心 C++ 功能，因此偶尔会更新。
如果您想向用户显示字符串，您可能必须考虑wchar_t（或其他库定义的类型）。不同的编译器和平台定义wchar_t不同，因为它们使用不同的 Unicode 编码技术。例如，在 Windows/Visual C++ 上，wchar_t是 16 位类型，适用于 UTF-16。例如在 GCC/Linux 上，wchar_t是 32 位类型，适用于 UTF-32。
IBM ICU 库具有用于从一种编码转换为另一种编码的转换功能。您的平台（例如 Win32）可能还具有从一种编码转换为另一种编码的功能。
根据您的要求（速度、内存使用），您应该选择适合平台的内部格式。在 Windows 上可能是 UTF-16，在 Linux 上可能是 UTF-32。这样您就不必一直对字符串进行转码，只需对它们进行简单的平台定义操作（wcslen()、wcscmp()等）。
对于外部格式（文本文件等），我倾向于使用 UTF-8。原因是如果文件包含西方语言的文本，则文件会小得多。另一个好处是您不必考虑 UTF-8 中的字节顺序，这降低了（您或其他人）出错的可能性。
IBM ICU 是一个用于处理 Unicode 字符串的非常大且功能强大的库。虽然，它可能是用大锤敲入一个小钉子。你需要它的所有功能吗？目标平台支持的 Unicode 功能可能满足您的要求。
原则上，是的，wchar_t可以随着新的编译器版本而改变（虽然它是一种语言特性，而不是库特性，所以它不依赖于库）。
在实践中，它突然改变大小的几率几乎为零。
不过，目前还不清楚你真正需要什么。wchar_t只允许您存储宽字符，仅此而已。ICU 是一个完整的 unicode 库，它可以做更多的事情，如果你想做比简单的打印字符串更复杂的文本处理，它是非常重要的。
最后，在 *nix 上，plainchar或std::string通常使用 UTF-8 编码，因此它们非常适合存储 Unicode 文本。 wchar_t由于这个原因很少使用。