将宽字符常量与 clang 结合使用获取“忽略宽字符常量中的无关字符”错误
我最近决定从 gcc 切换到 clang，并且由于使用宽字符常量而收到以下警告：“宽字符常量中的无关字符被忽略”。下面是收到警告的代码：
wstring& line;
…
for (wstring::iterator ch = line.begin(); ch != line.end(); ++ch)
switch (*ch) {
case L'│': *ch = L'|'; break;
case L'﹤': *ch = L'<'; break;
case L'﹥': *ch = L'>'; break;
case L'﹙': *ch = L'('; break;
case L'﹚': *ch = L')'; break;
default: break;
}
这里，case 条件中的字符都是高位 unicode 字符，因此显然被 clang 解析器视为多字节字符（源代码是 UTF-8 编码的）。
我的问题是警告消息背后的含义是什么。也就是说，到底什么被忽略了。另外，鉴于此警告，我的程序会按设计运行吗？
gcc 不会对此代码发出任何警告，并且一切都非常顺利。
I recently decided to switch to clang from gcc and I’m getting the following warning for my use of wide character constants: "extraneous characters in wide character constant ignored". Here is the code that gets the warning:
wstring& line;
…
for (wstring::iterator ch = line.begin(); ch != line.end(); ++ch)
switch (*ch) {
case L'│': *ch = L'|'; break;
case L'﹤': *ch = L'<'; break;
case L'﹥': *ch = L'>'; break;
case L'﹙': *ch = L'('; break;
case L'﹚': *ch = L')'; break;
default: break;
}
Here, the characters in the case conditions are all high-unicode characters and therefore seen as multibyte characters by the clang parser, apparently (the source code is UTF-8 encoded).
My question is what is the meaning behind the warning message. That is, what exactly is being ignored. Also, given this warning, will my program work as designed?
gcc does not give any warnings for this code and everything works like a charm.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
程序的核心是源文件的解释。您知道它是 UTF-8 编码的。这就是为什么 6 个字节
L'﹤'将被解释为 4 个 Unicode 字符。但 clang 怎么会知道呢？它看到 6 个字节，并假定采用 8 位编码。因此，它看到L'xyz'（精确的字符取决于假定的 8 位字符集）。 clang 告诉您它将L'xyz'解释为L'x'，忽略 y 和 z。按预期工作的可能性极小。At the heart of the program is the interpretation of the source file. You know that it's UTF-8 encoded. That's why the 6 bytes
L'﹤'are to be interpreted as 4 Unicode characters. But how would clang know? It sees 6 bytes, and assumes an 8 bit encoding. Thus, it seesL'xyz'(the precise characters depend on the assumed 8 bit character set). clang tells you that it is interpretingL'xyz'asL'x', ignoring y and z. It's extremely unlikely that works as intended.