GCC 下的 2 字节 (UCS-2) 宽字符串
当将我的 Visual C++ 项目移植到 GCC 时，我发现 wchar_t 数据类型默认为 4 字节 UTF-32。我可以使用编译器选项覆盖它，但 RTL 的整个 wcs*（wcslen、wcscmp 等）部分将变得不可用，因为它假定 4 字节宽的字符串。
现在，我已经从头开始重新实现了其中的 5-6 个函数，并在其中定义了我的实现。但是有没有更优雅的选择 - 比如说，GCC RTL 的构建，其中 2 字节 wchar-t 静静地坐在某处，等待被链接？
我所追求的 GCC 特定版本是 Mac OS X 上的 Xcode、Cygwin 以及 Debian Linux Etch 附带的版本。
when porting my Visual C++ project to GCC, I found out that the wchar_t datatype is 4-byte UTF-32 by default. I could override that with a compiler option, but then the whole wcs* (wcslen, wcscmp, etc.) part of RTL is rendered unusable, since it assumes 4-byte wide strings.
For now, I've reimplemented 5-6 of these functions from scratch and #defined my implementations in. But is there a more elegant option - say, a build of GCC RTL with 2-byte wchar-t quietly sitting somewhere, waiting to be linked?
The specific flavors of GCC I'm after are Xcode on Mac OS X, Cygwin, and the one that comes with Debian Linux Etch.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
查看 ICU 库。它是一个带有 UTF-16 API 的可移植库。
Look at the ICU library. It is a portable library with a UTF-16 API.
正如您所注意到的，wchar_t 是实现定义的。无法使用该数据类型进行移植工作。
一般来说，在 UCS-2 的失败被宣布为一个不太好的主意之后，Linux 系统的优势是后来获得了 Unicode 支持，并使用 UTF-8 作为编码。所有系统 API 仍然在 char* 上运行，并且是 Unicode 安全的。
最好的选择是使用一个为您管理此操作的库：Qt、ICU 等。
请注意，cygwin 具有 2 字节 wchar_t 功能，可以更轻松地与 Windows 进行啮合。
As you've noticed, wchar_t is implementation defined. There is no way to portable work with that data type.
Linux systems in general had the advantage of gaining Unicode support later, after the whole UCS-2 debacle was declared a not-so-great idea, and use UTF-8 as the encoding. All system APIs still operate on char*, and are Unicode safe.
Your best bets are to use a library which manages this for you: Qt, ICU, etc.
Note that cygwin features a 2 byte wchar_t to make meshing with Windows easier.
重新实现了 5-6 个更常见的 wcs* 函数，#define了我的实现。
Reimplemented 5-6 of more common wcs* functions, #defined my implementations in.
不。这是特定于平台的问题，而不是 GCC 问题。
也就是说，Linux 平台 ABI 指定
wchar_t是 32 位宽，因此您要么必须使用全新的库（ICU 是一个流行的选择），要么将您的代码移植到处理 4 字节wchar_t。您可能链接到的所有库也将假定为 4 字节wchar_t，并且如果您使用 GCC 的-fshort-wchar，将会中断。但具体到 Linux 上，几乎每个人都对所有多字节编码采用 UTF-8 进行标准化。
No. This is a platform-specific issue, not a GCC issue.
That is to say, the Linux platform ABI specifies that
wchar_tis 32-bits wide, so either you have to use a whole new library (for which ICU is a popular choice), or port your code to handle 4-bytewchar_ts. All libraries that you might link to will also assume a 4-bytewchar_t, and will break if you use GCC's-fshort-wchar.But on Linux specifically, nearly everyone has standardized on UTF-8 for all multibyte encodings.