c++ - Qt、MSVC 和/Zc :wchar_t- == I want to blow up the world

Question

所以 Qt 在 windows 上是用/Zc:wchar_t- 编译的。这意味着 wchar_t 不是某些内部类型(我认为是 __wchar_t)的 typedef，而是 unsigned short 的 typedef .真正酷的是 MSVC 的默认设置是相反的，这当然意味着您使用的库很可能是用 wchar_t 编译的。与 Qt 的类型不同 wchar_t .

当然，这不会成为问题，除非您尝试使用 std::wstring 之类的东西。在您的代码中；特别是当一个或多个库具有接受它作为参数的函数时。实际发生的情况是，您的代码可以愉快地编译，但随后无法链接，因为它正在使用 std::wstring<unsigned short...> 查找定义。但它们只包含期望 std::wstring<__wchar_t...> 的定义(管他呢)。

所以我做了一些网络搜索并找到了这个链接:https://bugreports.qt.io/browse/QTBUG-6345

根据 Thiago Macieira 的声明，“对不起，我们不会支持像这样构建 Qt”，我一直担心将 Qt 修复为像其他所有东西一样工作可能会导致一些问题，并一直试图避免它。我们使用/Zc:wchar_t- 标志重新编译了所有支持库，直到几天前我们开始尝试移植(我们正在从 Wx 切换到 Qt)一些序列化时，我们对此感到相当满意代码。

由于 win32 的工作方式，并且因为 Wx 只是包装了 win32，我们一直在使用 std::wstring表示字符串数据，目的是使我们的产品尽可能为 i18n 做好准备。我们做了一些测试，当尝试打印特殊的东西时，Wx 不能使用多字节字符(即使不是像度数符号这样特殊的东西也是一个问题)。我不太确定 Qt 是否有这个问题，因为 QString 不仅仅是底层 _TCHAR 类型的包装器，而且还是某种 Unicode 怪物。

无论如何，boost 中的序列化库已经编译了部分。我们已经尝试使用/Zc:wchar_t- 重新编译 boost，但到目前为止，我们试图告诉 bjam 这样做的尝试都没有受到重视。我们陷入了僵局。

从我坐的地方，我有三个选择:

重新编译 Qt 并希望它适用于/Zc:wchar_t。网络上有一些证据表明其他人已经这样做了，但我无法预测会发生什么。所有在论坛上询问 Qt 人员的尝试都没有得到答复。 hell ，即使在那个非常错误的报告中，有人问为什么，它就在那里呆了一年。

继续与 bjam 战斗，直到它听到为止。现在我手下有人在做这件事，而且我有更多的经验与事情斗争以获得我想要的东西，但我不得不承认我已经厌倦了。我还担心我会继续遇到这个问题，因为 Qt 想成为一个 c**t。

停止使用 wchar_t 做任何事情。不幸的是，我的 i18n 体验几乎为 0，但在我看来，我只需要在 QString(它有一个 BUNCH)中找到正确的 to/from 函数即可将 Unicode 编码为 8 字节，反之亦然。 UTF8 函数看起来很有希望，但我真的想确保如果来自某个地方的人使用更符号化的语言开始用他们自己的语言编写并且 QString 中的文档让我有点害怕认为可能会发生，则不会丢失任何数据。当然，我总是会遇到一些坚持使用 wchar_t 的库，然后我又回到了 1 或 2，但我很怀疑这会发生。

那么，我的问题是...

这些选项中哪个是我最好的选择？ Qt 最终会不会因为我决定用/Zc:wchar_t 编译它而导致我挖出自己的眼睛？

使用/Zc:wchar_t- boost build 的魔法咒语是什么，这会造成永久性的 spirit 伤害吗？

我可以只使用标准的 8 位(好吧，无论如何都是“通用”)字符类并符合 i18n 标准/准备好吗？

其他 Qt 开发人员如何处理这个烂摊子？

Answer 1

偶然发现了同样的问题......
显然 bjam 期望 cxxflags=-Zcwchar_t-
通过构建静态序列化库后
bjam --with-serialization toolset=msvc-8.0 variant=debug threading=multi link=static cxxflags=-Zc:wchar_t-
一切都像预期的那样联系在一起。

希望这可以帮助任何人。