所以Qt是用/ Zc：wchar_t-在windows上编译的。这意味着不是wchar_t是某个内部类型的typedef（我认为是__wchar_t），它就变成了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来表示字符串数据，目的是尽可能准备好我们的产品。我们做了一些测试，Wx在尝试打印特殊内容时没有使用多字节字符（即使不是像程度符号那样特殊的东西也是问题）。我不太确定Qt有这个问题，因为QString不仅仅是底层_TCHAR类型的包装，而是某种类型的Unicode怪物。
无论如何，boost中的序列化库已经编译了部分。我们试图用/ Zc：wchar_t-重新编译boost，但到目前为止，我们试图告诉bjam这样做的尝试都没有受到重视。我们陷入了僵局。
从我坐的地方我有三个选择：
重新编译Qt并希望它适用于/ Zc：wchar_t。网上有一些证据表明其他人已经做到了，但我无法预测会发生什么。所有在论坛等问Qt人的尝试都没有得到答复。天啊，即使在那个非常错误的报告中，有人问为什么，它只是在那里待了一年。
继续与bjam战斗，直到听。现在我有一个人在我这样做，我有更多的经验与事情争取得到我想要的东西，但我不得不承认厌倦了它。我也担心我会因为Qt想成为一个问题而继续讨论这个问题。
停止使用wchar_t进行任何操作。不幸的是，我的i18n经验几乎为0，但在我看来，我只需要找到QString中的函数（它有一个BUNCH）来将Unicode编码为8字节，反之亦然。 UTF8函数看起来很有前途，但我真的希望确保没有数据会丢失，如果某个地方有更多符号语言的人开始使用他们自己的语言编写，而QString中的文档会让我觉得可能会发生一些问题。当然，我总是遇到一些坚持使用wchar_t的库，然后我又回到了1或2但我怀疑会发生这种情况。
那么，我的问题是什么......
这些选项中哪一项是我最好的选择？ Qt最终是否会让我掏出自己的眼睛，因为我决定使用/ Zc编译它：wchar_t无论如何？
使用/ Zc：wchar_t-来构建强大的神奇咒语是什么？这会导致永久性的精神伤害吗？
我是否可以使用标准的8位（好的，“常见的”）字符类并且符合i18n标准/准备就绪？
其他Qt开发者如何应对这种混乱？
答案 0 :(得分：7)
我同意ÖöTiib的评论
这个选项也许就是为了 兼容一些旧的遗产 pre-wchar_t代码。
考虑到Qt被移植到许多不同的平台（包括嵌入式系统），其中一些没有一个像样的C ++编译器，我猜这个开关只是为了在这些平台上编译Qt成为可能。我的意思是，Qt可能不依赖于正常工作。如果是这样的话，那将意味着Qt的设计在我看来已经深深打破。所以选项1应该有效。
话虽如此，我肯定会建议选择选项3，因为
wchar_t几乎没有任何内容
关于i18n 您可以查看在results列表中搜索wchar_t的{{3}}，在那里提出您的问题并在qt-interest@qt.nokia.com #qt irc频道与Thiago Macieira交谈蒂亚戈非常活跃。
答案 1 :(得分：5)
偶然发现了同样的问题......
bjam显然希望cxxflags=-Zcwchar_t-
通过
构建静态序列化库之后 bjam --with-serialization toolset=msvc-8.0 variant=debug threading=multi link=static cxxflags=-Zc:wchar_t-
一切都像预期的那样联系在一起。
希望这有助于任何人。
答案 2 :(得分：0)
wchar_t应该类似bool或long。没有标题来定义它。
您确实使用了“wchar_t is undefined type”选项。然后你输入def wchar_t作为unsigned short然后你想知道什么都不行了？
该选项可能是为了与一些旧的传统pre-wchar_t代码兼容。只是......从不使用它。否则，没有C ++链接到它，因为采用wchar_t参数的函数与采用无符号短参数的函数的名称不同。
如果使用一些奇怪的选项编译某些库，则使用正确的选项构建它。需要时，然后修复其代码。如果你不能这样做，那么你不应该使用该库。 C ++项目中的每一行代码都是您需要维护的。
答案 3 :(得分：0)
将此作为答案，因为评论时间过长。
这是为什么一个人可能会获得LNK2019又名＆＃34;未找到符号的答案之一＆＃34;链接器错误（source）：
- 您将使用本机wchar_t的代码与不具备该代码的代码混合在一起。在Visual C ++ 2005中完成的C ++语言一致性工作 wchar_t默认为本机类型。您必须使用/ Zc：wchar_t-
编译器选项，用于生成与由VB编译的模块兼容的代码 使用早期版本的Visual C ++。如果不是所有模块都是
通过使用相同的/ Zc：wchar_t设置编译，类型引用可以是 不解析兼容类型。验证所有的wchar_t类型 通过更新所使用的类型，模块是兼容的，
或者在编译时使用一致的/ Zc：wchar_t设置。
因此可能是所有与cl.exe相关的mkspec文件中存在/ Zc：wchar_t-的主要原因以及为什么你可能不需要它。
我喜欢使用原生wchar_t因为它有时很容易在windows api期望的字符串和QString之间进行转换。