Qt,MSVC和/ Zc:wchar_t- ==我想炸毁这个世界

Edw*_*nge 36 c++ qt boost internationalization

因此Qt在Windows上用/ Zc:wchar_t-编译.这意味着不是wchar_t是某个内部类型的typedef(我认为是__wchar_t),它就变成了一个typedef unsigned short.关于这一点非常酷的是MSVC的默认值是相反的,这当然意味着你正在使用的库可能与wchar_tQt的类型不同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函数看起来很有前途,但我真的希望确保如果来自Zimbabfuckegypt的人开始使用他们自己的语言编写并且QString中的文档让我想到可能发生的事情,那么数据就不会丢失.当然,我总是遇到一些坚持使用wchar_t的库,然后我又回到了1或2但是我怀疑会发生这种情况.

那么,我的问题是什么......

以下哪个选项是我最好的选择？Qt最终会让我掏出自己的眼睛,因为我决定用/ Zc:wchar_t编译它吗？

什么是使用/ Zc来加强构建的神奇咒语:wchar_t-并且会导致永久性的精神伤害吗？

我是否可以使用标准的8位(好的,"常见的")字符类并且符合i18n标准/准备就绪？

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

Pio*_*ost 7

我同意ÖöTiib的评论