有没有玩过 qt 的

[zhiwoda123]

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

[ipwx]

用 gcc 啊，送分题，下一问

[deorth]

windows 用 mingw

[firemiles]

没楼主 linux 下装个 qt 玩下就知道了

[hsuehsen]

不同平台，用各自平台的编译器编译就可以

[cjw6]

不要用各自平台的 api，用 qt 的 api，c++跨平台特性，可以直接跨平台编译

[xiri]

ubuntu 下肯定用 gcc 啊
qt 是跨平台的，api 都是通用的，代码不需要动，装好 linux 版的 qt 直接编译就行了
不过有一些组件还是需要注意一下，比如 mingw 下没法使用 webengine （不记得名字对不对，反正就是 webview 相关的）

[bayunjue]

qmake，cmake 都可以

[hhyvs111]

不能编译，坑很多

[zhiwoda123]

@xiri 大佬我刚学 qt 不是很懂，我想问一下假如 win7 平台 qt 用的 msvc2015 编译器写的代码，ubuntu 上面 qt 用的 mingw 可以编译 win7 拷贝过来的代码吗

[xiri]

@zhiwoda123 ubuntu 下直接用 gcc 啊，mingw 是 windows 下的

至于 win 下写的代码放到 ubuntu 下编译，问题应该不是很大，qt 本来就是主打跨平台的，就算要改应该也不是啥大问题。
我用 qt 也不是很多，就自己写了一些小工具，都是换个编译器就能直接跑动的，唯一碰到的就是上面提到的有些组件 mingw 下没有点问题了

[ipwx]

@zhiwoda123 大部分代码没问题。少部分你可以用宏 #ifdef 控制一下。

https://blog.kowalczyk.info/article/j/guide-to-predefined-macros-in-c-compilers-gcc-clang-msvc-etc..html

[dalieba]

@xiri 如果把 mingw 换成 Clang 会怎样？

[ipwx]

@dalieba 其实 win 下面还是 msvc 最靠谱

[GPLer]

@dalieba 如果写法标准基本没影响，不要用 GCC 的语法糖就行。

[reus]

你自己试一下不就知道了
linux 哪来的 msvc?

[4thirteen2one]

这个......和编译器没关系吧......除非你有一些指定的依赖项只有 win 里面有。话说可以尝试一下 pyqt

[ztcaoll222]

可以尝试用下 msys2

[aa514758835]

不用吧，如果你写的代码没有依赖平台，都用 Qt 的，直接拷贝代码过去编译即可，

[dixeran]

只要你用的都是 Qt 的接口，没引用 windows.h 或者调用系统相关 API，那编译器用哪个都没关系。

[wbing]

ubuntu 下面没有 msvc2015。
只要你没用 win 下特有的 api，代码能直接编译过的。
用 msvc 编写出来的程序可以在 windows 下打开，gcc 编译出来的可以在 linux 下打开。

[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 而是依赖项的发行商的问题，也实在没法认为是靠谱的表现吧。