有没有玩过 qt 的

[zhiwoda123]

假如我再 windows 上面写的 qt 程序编译器是 msvc2015，然后把代码拷贝到 ubuntu 环境，在 ubuntu 环境下用 qt 编译，编译器要和 windows 的 qt 一样吗？？？

[FrankHB]

@ipwx 都是 bug 一坨坨，看不到源码我没法修的怎么就更靠谱了？

[ipwx]

@FrankHB MSVC 是 windows 下的标准。

别的程序给的 DLL/LIB 都用 MSVC 编译的，你要用，你只能用 MSVC。

再说了，微软自家的东西，当然是微软自己最清楚。我还不信任 mingw 呢。

[FrankHB]

@ipwx MSVC 自己（而不是有强迫症的 MSVC 用户）有能称得上 Windows 下的标准的东西？有多少东西找得到跟实现准确匹配的文档？ ABI 都没敢全说清楚吧？
同等功能同等质量的实现，没源码比起有源码的就是残次品；都有源码的，依赖特定实现导致兼容性更差的更残废。既然已经在一部分实现上废了，能给全文档让人脑补逆向出源码也差强人意，逼用户从二进制逆向出来才能弄清楚实际干了坨什么的，就别好意思标榜靠谱了。然而讲个笑话，关于 MSVC 的一些东西，看 LLVM 的材料都可能比 MS 家的靠谱……再讲个笑话，直到近几年前升级 MSVC 还会 break ABI。还有一堆笑话，msvcrt 和 ucrt ……
，这不是常识么。
这还就只是人力可以做到的逆向。升级个编译器版本多出来一坨 ICE，没源码人肉修编译器试试？
除了谁都做不到的，没能力折腾好就认，跟信任几毛钱关系。
还有，别家工具链不管是 conformance 还是 compatibility 很多情况就是库拙计的问题，cl 前端整个烂了那么多年，bug-to-bug compatible to MSVC 的东西，有源码看都能发现普遍更不靠谱。

[FrankHB]

编辑框抽风漏了。
“，这不是常识么。”
→
“把能填的坑填过了，或者至少评估过填坑的难度，再讨论靠谱程度。到处都有人在用又不保证你自己的和别人普遍的用例中能满足需求，这不是常识么。”

[FrankHB]

@ipwx 还有啊，“你只能用 MSVC ”？× ——这是乐观过头了。
实际不少情况是只能用特定版本的被支持的 MSVC，直到甩掉这整坨屎。
说个实际案例吧。
几年前给人糊一坨 Pro/E 之类的插件，本来 VS2010 用得好好的，然后因为只给 lib 就要愣是要 VS2008，更可笑的是还只能用 libcmt 没法上 msvcrt ……最后一坨用 MSBuild 的 sln 还要拖一坨魔改过的 nmake，一台 2G 的穷酸开发机上同时开两个 VS 和一坨客户程序联调，那酸爽。。。
说 MSVC 是标准是吧……那这里到底是 VC2010 是标准还是 VC2008 是标准呢？用 MSBuild 是标准呢，还是 nmake 是标准呢？（现在 nuget 一过气，又可以一起纠结 vcpkg 和 conan 了……）
倒不是说不用 MSVC 就一定能避免这种问题，问题是别的替代实现真没那么多乱七八糟需要 version lock-in 的东西。
而且不管怎么说这种问题就算主要不是 MSVC 而是依赖项的发行商的问题，也实在没法认为是靠谱的表现吧。