在将我的 Visual C++ 项目移植到 GCC 时，我发现 wchar_t 数据类型默认为 4 字节 UTF-32。我可以使用编译器选项来覆盖它，但随后 RTL 的整个 wcs*（wcslen、wcscmp 等）部分将变得不可用，因为它假定为 4 字节宽的字符串。
现在，我已经从头开始重新实现了 5-6 个这些函数并#defined 我的实现。但是有没有更优雅的选择 - 比如说，一个 2 字节 wchar-t 的 GCC RTL 构建静静地坐在某个地方，等待被链接？
我所追求的 GCC 的特定风格是 Mac OS X 上的 Xcode、Cygwin 以及 Debian Linux Etch 附带的一种。
但是有没有更优雅的选择——比如说，一个带有 2 字节 wchar-t 的 GCC RTL 的构建静静地坐在某个地方，等待被链接？
不，这是特定于平台的问题，而不是 GCC 问题。
也就是说，Linux 平台 ABI 指定它wchar_t是 32 位宽，所以要么你必须使用一个全新的库（ICU 是一个流行的选择），要么移植你的代码来处理 4 字节wchar_t。您可能链接到的所有库也将假定为 4 字节wchar_t，并且如果您使用 GCC 的.-fshort-wchar
但特别是在 Linux 上，几乎每个人都已将所有多字节编码的 UTF-8 标准化。
看看ICU 图书馆。它是一个带有 UTF-16 API 的可移植库。
正如您所注意到的， wchar_t 是实现定义的。无法移植使用该数据类型的工作。
Linux 系统通常具有后来获得 Unicode 支持的优势，在整个 UCS-2 崩溃被宣布为一个不太好的想法之后，并使用 UTF-8 作为编码。所有系统 API 仍然在 char* 上运行，并且是 Unicode 安全的。
你最好的选择是使用一个为你管理这个的库：Qt、ICU 等。
请注意，cygwin 具有一个 2 字节的 wchar_t 以使与 Windows 的网格化更容易。
重新实现了 5-6 个更常见的 wcs* 函数，#defined my implementations in。