代码工程/Qt 开发环境提升（2）

最新推荐文章于 2024-07-10 17:23:17 发布

大河qu

最新推荐文章于 2024-07-10 17:23:17 发布

阅读量778

点赞数

分类专栏： IDE集成开发环境文章标签： Qt开发环境 Qt调试异常

本文链接：https://blog.csdn.net/quguanxin/article/details/109191878

版权

IDE集成开发环境专栏收录该内容

18 篇文章 3 订阅

订阅专栏

文章目录

概述
编译问题
- macro name is a reserved identifier
运行问题
编辑问题
- 无法使用高级搜索
- 代码文件无法输入中文
GDB调试
调试乱码问题
控制台的使用
断言使用

概述

Here，续接 C++/Qt 开发环境提升（1），它主要讲解了Qt 4.8.6的源码编译方法（源码编译，是进行Qt程序深入调试的基础），编译注意事项，Qt帮助系统，Qt学习方式等。本博文将记录在使用Qt集成开发环境过程中遇到的实际问题…

编译问题

macro name is a reserved identifier

在这里插入图片描述
在学习QtCreator架构时，打开了帮助 - 关于插件 - C++ - ClangCodeModel插件，结果就有上述提示。未继续深究Clang！

运行问题

单步调试-结构体局部变量

刚刚发现了一个奇怪的问题，在使用QtCreator进行F10单步调试时，函数内部的结构体变量，即使是加上断点也走不到，且运行到该行时，断点符号会消失。初步感觉上，是程序没有编译好，但是重新完全编译后，依然存在该问题，勾起了我的好奇心。于是乎单独的写了一个测例，测试结果说明了，局部的结构体变量，如果这个结构体没有构造函数（无关乎结构体组成元素的类型），则在进行QtCreator下的gdb调试时，定义局部结构体变量的这一行，不会走到。然后，我打开了好久不用的VS，发现其测试结果与上述一致，在一行结构体(无构造函数)局部变量定义代码前边加上断点标记符号，但是在进行调试运行时该标记会自动消失，即不能断在该行，单步调试也不走它。

另外，发现这个局部的结构体变量，在进行memset前极有可能出现不是全零的情况，因此对于结构体变量的memset初始化过程，并不是可有可无的。

Qt 定位内存起始地址失败

    int  hex1 = 0x1234;
    uint hex2 = 0x1234;     //无法直接调试内存
    quint32 hex3 = 0x1234;  //无法直接调试内存
    unsigned int hex4 =0x1234;

在QtCreator调试环境-本地变量与表达式（Locals and Expressions）窗口，右键，查看变量对应的内存，如下图，Open Memory View at Object’s Address / Memory Editor at Object’s Address，处于灰色禁用状态。（Here该是QtCreator4.4.1的一个缺陷）

hex1可以跳转到变量地址	hex2不可以跳转到变量地址（灰色）

进一步测试这个缺陷发现，对于使用int、unsigned int直接定义的变量，使用[打开内存编辑器]功能时，可以直接准确跳转到变量起始地址（Open Memory View at Object’s Address），但是当你使用uint、quint32等数据类型（ttypedef unsigned int uint/quint32 ）定义变量时，就出现了上图右侧的显示风格(灰色，无法信息接收)。

查看U8*的变量

试图在变量监视窗口看一个U8指针的值，结果显示为0，不要惊慌，你只是没有选对数据展示格式。

修改方案如下，选中上述第一幅图中粉色标记位置，右键–

编辑问题

无法使用高级搜索

这里指的是在QtCreator中无法使用 Ctrl+Shift+F 组合按键，打开IDE的高级搜索功能。在办公机器（Win7系统）存在这样的问题，知道其与搜狗输入法有关，因为只要在使用上述组合键时，先按Ctrl+Shift+空格将输入法隐藏，则可以正常打开QtCreator高级搜索。但是这招在Win10机器上却不管用。后来多方查证，关闭了搜狗输入法-属性设置-高级-系统功能快捷键-取消简繁切换的勾选，问题解决。

代码文件无法输入中文

[QtCreator无法输入中文]，在使用QtCreator编辑器时，偶尔遇到过在.h或.cpp文件编辑时无法输入中文的情况：输入法显示搜狗中文，但是当你敲击键盘时，没有弹出来中文候选字，而是直接将英文字母输入进去了。后来，总结了这种现象的原因。

Qt文件编辑器的默认设置	文件实际编码与本地默认编码不一致时

“无法输入中文的状况就出现在上述情景下”，当我们选择了按照实际代码文件编码格式重新载入显示时，（如上述情况，本地默认是ANSI，但是代码文件是UTF的，选择按UTF8重新载入），此时再对代码文件进行编辑，则问题出现。解决办法是，使用NotePad等工具，转换代码文件为QtCreator本地默认编码格式，然后重新打开再进行编辑就好了！

GDB调试

参见

调试乱码问题

Qt5 中文乱码解决方法剖析 # https://blog.csdn.net/li_jian_xing/article/details/47609621

控制台的使用

一直有个疑问：不管是系统控制台，还是QtCreator控制台，多线程访问控制器输出时，它们能否保证显示顺序就是真实的运行顺序 ?

在进入这个问题前我们先来看看控制台基础概念。在MSDN上有一部分关于Console的资料，可以找找你想要的答案！控制台有一个输入缓冲、至少一个屏幕缓冲（输出缓冲）构成。多个进程可共享一个控制台。其实到现在，骨子里我是相信在多线程下Console显示能保证与实际系统运行顺序一致的，但是打印看上去有点怪？而这种所谓的怪现象，可能并不怪，这可能是CPU执行策略导致的，那么我们应该去研究CPU时间片、轮循、CPU等待、并行执行等概念！

关于多线程的执行，我有一堆问题没有搞明白，这个以后单独开一篇boke。先看看这个问题：在多核CPU下，同一进程下的多个线程可不可以并行运行 ? 也许对想搞明白什么有所帮助。另外，用户应用程序中，能否通过底层接口感知到自己的执行cpu、直接的执行时间、等待时间等？

断言使用

define Q_ASSERT_X(cond, where, what) ((!(cond)) ? qt_assert_x(where, what,__FILE__,__LINE__) : qt_noop())
 
int qAllocMore(int alloc, int extra)
{
    Q_ASSERT(alloc >= 0 && extra >= 0);
    Q_ASSERT_X(alloc < (1 << 30) - extra, "qAllocMore", "Requested size is too large!");
 
    //控制台打印信息
    //ASSERT failure in qAllocMore: "Requested size is too large!", file tools\qbytearray.cpp, line 73
 
}
 
//请继续学习qt_assert_x的实现过程

“__FILE__”：在源文件中插入当前源文件路径及文件名； __LINE__：在源代码中插入当前源代码行号；