使用VS调试Qt Creator创建的工程

版本说明

在介绍之前先给个试验环境的说明:

• VS Enterprise 2017 V15.9.20
• QT VS Tools 2.4.3
• QT Qt 5.12.0

为什么要用VS来调试Qt Creator的工程？

作为专用型的IDE，大部分的场景下Qt Creator足够用，而且对我自己来讲我更喜欢Qt Creator，因为其有着更简洁的窗口，原生编辑器的字体高亮，舒服简洁的目录组织，更容易被读懂的工程配置（.pro）。可以说，Qt Creator更懂Qt，谁让是一个爹妈生的呢。虽然大多时候Qt Creator都挺好，它也是我绝大部分的时间里用来开发Qt工程的环境，但是总有一些另外：

糟糕的调试体验

这里主要说Qt Creator + Cl编译器的体验，在使用Qt Creator + MingW的编译器以下部分非关键性问题会有些改善，但痛点问题的体验好不到哪去。Qt Creator在使用Cl调试器时，调试体验很糟糕。小慢且不说，还能忍受（烦的时候吧，其实也不太能忍，影响我挥刀斩bug的快感）。主要有两个问题：变量查看和单步调试。

• 变量查看。变量的查看只能在固定框中查看，不能就地查看就不能忍了，太影响效率，有时还会解析不出变量值。在调试数据量大的容器时问题就更大了，调试过程异常卡顿，而且只能查到有限的数据量，有时甚至直接放弃解析变量的值。
• 单步调试。单步调试会有代码跳转不按照期望的执行的情况，比如我想单步进入函数，但是调试不知道跑到了哪里，代码没有任何的跳转。注意，这里的不是进入了库的二进制，因为调试进入库的二进制也会跳转到汇编。

分析工具支持弱

Qt Creator几乎没有分析工具，除了编辑器基本的代码审查外，其他什么也没有。每当你遇到一起奇怪的bug时，你会想念VS的分析工具。比如我当前想分析一下CPU的使用情况。

怎么用VS来调试Qt Creator的工程？

1. 给VS安装Qt插件
2. 使用插件解析.pro文件
3. 编译工程
4. 解决当前版本VS基本必出的bug——QMeta…的linker

该错误显示如下图所示：

关于QMeta…的linker错误，解决办法就是把Crtl + Shift + F查找所有 “Q_Object” 宏，Ctrl + X ，Ctrl + V，保存所有，编译，打完收工。使用QT VS Tools解析**.pro文件后，打开项目的属性中没有下面图中提示的Qt Meta-Object Compiler和Qt User Interface Compiler**，这一步实际上就是让VS的QT插件知道需要用到这些编译器。这个bug是VS中Qt插件的bug，到我目前使用的版本中仍然没有得到解决。

这里有个小技巧，如果Q_OBJECT使用了太多地方你一个个找到去替换太麻烦了，可以Ctrl + Shift + F替换所有“Q_OBJECT”为“Q_OBJECT”，没错就是替换自己。替换对话框中VS很贴心地告知修改后只有打开的文件才能撤销，所以有个建议让用户勾选上以打开所有修改的文件，这是个后悔药啊。

注意，是替换整个解决方案中的所有的文件，而不是其他选项，避免错误地替换电脑中其他的文件。本来替换自己是没有问题，不过如果你们电脑上也被安装了加密软件，触发修改导致加密，那还是很恶心的。

如果只是为了让VS可以调试Qt Creator的工程这已经够了，不过作为一个有追求的工程师，下面将讲解在使用VS调试Qt Creator工程遇到的其他问题。

其他问题

VS复用build路径

在Qt Creator中做了一个很好的示范，在编译项目时，会在项目的同级目录中生成默认的build路径，以实现过程文件、可执行文件和代码分别存放，这有利于代码的管理。当转到VS来调试Qt Creator工程时，使用VS的Qt插件来打开.pro文件来解析，默认的生成路径则完全不同，而且代码和过程文件、可执行文件都放到了项目目录。既然我们只是使用VS来调试下Qt Creator的工程，自然不希望调完原来的项目文件夹就被污染了，我们希望复用Qt Creator的默认build路径。

先来看一下Qt Creator生成的默认build路径，以Debug模式生成的路径为例，如下图：

然后在VS中右击项目选择properties，根据上图，一层层地来设置对应的路径以达到复用的目的：

• 指定ui_xxx.h文件位置，在Qt User Interface Compiler的Output Directory配置ui_xxx.h文件所在的目录，即build-xxx-Debug（可以直接配置绝对路径，下同）。
• 指定moc_xxx.h，moc_xxx.cpp文件位置，分别在Qt Meta-Object Compiler的Include和Output Directory配置moc_xxx.h和moc_xxx.cpp文件所在的目录，即build-xxx-Debug/debug。
• 指定qrc_xxx.cpp文件位置，在Qt Resource Compiler的Output Directory配置qrc_xxx.cpp文件所在的目录，即build-xxx-Debug/debug**。
• 指定xxx.dll和xxx.exe文件位置，在General的Output Directory配置xxx.dll和xxx.exe文件所在的目录，即build-xxx-Debug/debug。
• 指定moc_xxx.obj、xxx.obj、xxx.pdb文件位置，General的Intermediate Directory配置moc_xxx.obj、xxx.obj、xxx.pdb文件所在的目录，即build-xxx-Debug/debug。
• 另外还有一个特别重要的目录Working Directory，这个路径用来指定在IDE启动程序时进行路径访问的默认位置。在我试验的工程中，没有使用Qt Creator的默认Working Directory，而是设置Working Directory为.pro所在位置，而VS的Qt插件解析**.pro会在其同级目录生产.vcxproj文件。所以Debugging中的Working Directory恰好是$(ProjectDir)，而这个宏展开就是.pro所在目录。如果使用Qt Creator的默认Working Directory**，这里也需要改成build-xxx-Debug/debug。

指定了上面的目录后再次运行程序，发现已经复用了Qt Creator的做法——代码和过程文件、可执行文件的分离，VS还是会在代码目录生成一些必要的VS配置，如**.vcxproj**文件、x64\Debug\qmake文件下的一些文件等，这已经无伤大雅了。

C++ IntelliSense警告去除

VS的IntelliSense是一个不错的工具，详细的介绍见微软官方文档Visual C++ IntelliSense 功能，顺便说一句，中文的哦。简单总结就是这个VS用来自动补齐代码，并能根据收集的信息给出警告标注的工具。

在用VS来调试Qt Creator的工程时，其会给Qt工程标注大量刺眼的红色警告，提示找不到包含的头文件，以及找不到一些宏定义。这不影响编译，因为在编译所需要查找的Include路径已经在C/C++的Additional Include Directories给出了。这里多插一句，Additional Include Directories是三方库的头文件头文件不在我们的项目中，如Qt库的一些头文件，我们只需要可以访问到即可。

另外编译时需要链接导入库，在Linker->General的Additional Library Directories指定动态连接库的位置和Linker->Input的Additional Dependencies指定lib库的文件名。

如何去掉这些大量的警告呢？只需在VC++ Directories的Include Directores中指定**$(Qt_INCLUDEPATH_)** 和 代码工程中所有用到的.h文件的路径即可。因为该属性默认只包含了Windows SDK的Include路径和VC的Include路径，而IntelliSense工具以此路径为依据来完成其工作。

不知道算不算IntelliSense本身设计上欠考虑，现在要求插件的开发者很好地理解其意图，并及时地匹配其新特性，对于一个非商业的插件来说太难了（VS Qt tools千疮百孔可见一斑）。虽然这些警告并不影响编译，但是如果你使用VS来写Qt工程，你会发现很需要这个IntelliSense功能。当然，作为一个有追求的工程师，我也不容许这样的警告出现在我的工程里。也许你还会看到一些，比如E2512From qcompilerdetection.h 1349，且随他去吧。据说是IntelliSense的bug，升级一下VS就好了，不过我已经把VS2017上面的更新更完了，还是没有解决，无伤大雅就任它去吧。