目前我们MiniDumpWriteDump用MiniDumpNormal | MiniDumpWithIndirectlyReferencedMemory旗帜打电话.这适用于Debug配置中的内部构建,但是没有提供我们在Release配置中所需的尽可能多的信息.
在Release中,minidump数据包含足够的堆栈信息,以便调试器计算出代码中发生故障的位置,但没有其他数据.我不仅仅意味着由于优化而缺少局部变量,正如您在Release版本中所期望的那样 - 我的意思是除了调用堆栈和当前代码行之外没有任何其他用处.没有寄存器,没有本地,没有全局,没有当地人指向的对象 - 什么都没有.我们甚至没有得到'this',这将允许我们查看当前对象.这是使用点MiniDumpWithIndirectlyReferencedMemory- 它应该包含本地和堆栈变量引用的内存,但似乎不是.
我们应该使用什么标志呢？我们不想使用MiniDumpWithFullMemory并开始生成600MB +转储,但如果它意味着获得更多有用的数据,我们很乐意将转储扩展到我们目前获得的90KB之外.也许我们应该使用MiniDumpWithDataSegments(全局)或......？
MS Visual Studio 2008中的C++.警告级别4加上一系列额外警告也已启用.我希望这至少会发出警告,但更可能是编译错误？
功能声明如下:
int printfLikeFunction(
const int bufferLength,
char * const buffer,
const char * const format,
... );
代码用法 - 有一个错字:虽然传入了outputBuffer的ARRAY_SIZE,但outputBuffer本身并不是 - 当然这不应该编译:
printfLikeFunction( ARRAY_SIZE( outputBuffer ), "Format: %s, %s", arg1, arg2 );
显然这是错误的,并且已经犯了错误.但是编译器应该抓住它!buffer参数应该是一个char-pointer,并且它正在传递一个字符串文字,这是一个const char-pointer.这一定是个错误.(arg1和arg2也是(可能是const)char指针,所以巧合的是声明匹配,即使没有outputBuffer在正确的位置).
在运行时,此代码在尝试写入字符串文字时崩溃.毫不奇怪,我只是不明白如何允许编译.
(虽然顺便说一句,这可能是为什么sprintf_s的缓冲区和大小参数与此函数的顺序不同 - 它会使这些错误明确失败).
假设一个人继承了一个复杂的代码库(在Visual C++中,假设2003或者更晚),它具有大而复杂的继承图.假设它很深,并且有很多虚函数,甚至可能还有多重继承.(是的,有点像维护噩梦).任何将此类层次结构重构为更合理的尝试都需要知道每个类使用的每个虚函数的哪个实现.
如果我们采用任意叶类L1 - 它派生自基类B1,它派生自基类B2等 - 它将显然具有类的vtable,它将显示类似于(伪vtable)的类:
L1::F1
B3::F2
B1::F3
L1::F4
etc.
...具体取决于哪个类被哪些虚函数覆盖了.
怎么能看到像这样的形式的vtable呢？可以通过阅读代码手动重建它,但这很容易出错且费力.据推测,在调试器中打破类的对象可能允许您通过该类的vtable指针检查Watch窗口中的vtable,但这是一个尴尬的解决方案,特别是如果您还想查看L2的vtable, L3,... LN.
DbgHelp.dll是否提供了以编程方式检查vtable的工具(允许以任何形式输出)？还是有其他方法吗？
我刚刚被赋予了将遗留应用程序从32位更新到64位的任务.在查看任务的范围时,我在包含外部(例如平台)标头之前立即发现了以下定义:
#define POINTER_32
我找不到使用这个定义或它有什么效果的东西,但它看起来像是与我的任务直接相关的东西!
它是为了什么？有什么用？立即将其移除是否安全(我认为从长远来看有必要将其移除)？
这是使用MS VC++ 2008,很快将是2010年.