Inspector XE 2013 实现了和Visual Studio* IDE中调试器的对接

众说周知,Inspector XE是对动态执行的程序进行错误追踪,然后在程序退出后,显示错误报告。Inspector XE 不会干预程序的正常进行,一般也不暂停程序的执行,除非你有这方面的要求。例如在Linux环境下,Inspector XE 2011 可以实现与GDB调试器的无缝连接

 

Windows 的开发环境,Inspector XE 2013 不仅提供了“遇错即停”的功能,而且可以提供设断点(Breakpoint)功能,下面具体描述此功能的应用。

注意,在Windows的开发环境,debug功能的对接仅适用Visual Studio* IDE的集成环境。换言之,命令行和独立应用程序不支持此功能。

 

当你的应用程序Build完成后,选择Inspector XE的“New Analysis”,在“Configure Analysis Type”中,一定不能选“Detect Leaks”(因为Inspector 不会再程序运行中报Memory Leak的错误,一定是在程序退出后),所以不会出现“Debugger”的选项。

 

三种方式

1. Analyze without debugger : 这就是我们平时用的,不干预运行,结束后看出错报告

2. Enable debugger when problem detected: 运行Inspector的分析,遇到任何一处出错,把控制权交给Debugger,且程序停在出错处。

3. Select analysis start location with debugger: 利用Debugger,可以在任何的代码起始处开始Inspector的分析。一般而言,要在需要分析的代码起始处设置“断点”。

 

第一种情况,我们不再解释。

第二种情况,主要是对遇到的错误进行定位分析。当然也可以看事后出错报告。

关键的是第三种情况。起始状态Inspector的分析是不工作的,用户意图设立断点,跳过“已知”的错误,如下图

Inspector执行此种方式时,其实是Debugger 运行,Inspector不工作

 

Inspector 会停在用户设立的断点位置,然后Inspector 恢复查错,程序结束,Inspector 产生出错报告

进一步说明的是,如用户不设断点,Inspector就不恢复查错,出错报告的内容为空。

第三种情形的积极意义在于:用户可以让Inspector的分析从自己感兴趣的代码开始(在此设立断点),建议在上个函数的出口或本函数的入口

For more complete information about compiler optimizations, see our Optimization Notice.