关于DEBUG和RELEASE的一些问题及解决方法
- 格式:doc
- 大小:94.50 KB
- 文档页数:12
代码调试中的常见问题与解决方法代码调试是程序开发过程中一个非常重要的环节,但常常会遇到各种问题,导致开发进度延误。
下面将介绍一些常见的代码调试问题及解决方法,希望对大家有所帮助。
1.语法错误语法错误是最为常见的问题之一,如果代码中存在语法错误,程序将无法正常运行。
通常会出现拼写错误、缺少分号等问题。
在这种情况下,编译器会给出相应的错误提示,如缺少分号、拼写错误等信息。
解决方法是仔细检查代码,对照错误信息进行修改。
2.逻辑错误逻辑错误是指程序逻辑上的错误,导致程序无法按照预期的方式运行。
有时候程序可以正常编译并且运行,但是结果却不正确。
这种情况下,需要通过调试工具进行逐步调试,找出程序逻辑上的错误,并进行修正。
3.内存泄漏内存泄漏是指程序在运行过程中分配了内存空间但没有及时释放,导致内存占用不断增加,最终导致程序崩溃。
通常情况下,内存泄漏会导致程序变得越来越慢,直至最终崩溃。
可以通过内存调试工具检测内存泄漏问题,并进行相应的修复。
4.程序崩溃程序崩溃是指程序在运行过程中突然停止工作的现象,通常会出现错误提示。
常见的程序崩溃原因包括访问非法内存、栈溢出等。
解决方法是通过调试工具跟踪程序执行过程,找出程序崩溃的原因,并进行相应的修复。
5.性能问题性能问题是指程序在运行过程中性能较差,例如运行速度慢、资源占用高等。
通常情况下,性能问题会导致程序体验不佳,甚至影响用户体验。
可以通过性能分析工具进行性能测试,找出性能瓶颈并进行优化。
6.死锁问题死锁是指两个或多个进程在执行过程中,由于竞争资源导致相互等待,进而导致程序无法继续执行的情况。
通常情况下,死锁问题很难排查,需要通过调试工具进行分析,找出死锁的原因,并进行相应的处理。
总的来说,代码调试是程序开发过程中不可或缺的一部分,但也是一个复杂而繁琐的工作。
在遇到问题时,我们应该耐心、细心地进行排查,并利用各种调试工具来帮助我们解决问题。
只有不断提升自己的调试技能,才能更好地完成程序开发工作。
Makefile条件编译debug版和release版⼀般,在开发测试阶段⽤debug版本,⽽上线发布⽤release版本。
使⽤Makefile定制编译不同版本,避免修改程序和Makefile⽂件,将会⼗分⽅便。
读了⼀些资料,找到⼀个解决⽅法,Makefile预定义宏与条件判断,结合make预定义变量,进⾏条件编译。
⽐如,有⼀个test.cpp,包含这段代码#ifdef debug//your code#endif你希望在debug版本要执⾏它,在release版本不执⾏。
我们可以写这样的⼀个Makefile:1 ver = debug23 ifeq ($(ver), debug)4 ALL: test_d5 CXXFLAGS = -c -g -Ddebug6else7 ALL: test_r8 CXXFLAGS = -c -O39 endif1011 test_d: test.do12 g++ -o $@ $^1314 test_r: test.ro15 g++ -o $@ $^1617 %.do: %.cpp18 g++ $(CXXFLAGS) $< -o $@1920 %.ro: %.cpp21 g++ $(CXXFLAGS) $< -o $@简单说⼀下,Makefile根据ver的不同定义了不同的编译选项CXXFLAGS与输出程序ALL,debug版本输出程序是test_d,release版本输出程序是test_rdebug版本编译选项是"-c -g -Ddebug",release版本编译选项是"-c -O3"debug版本object⽂件后缀是".do",release版本object⽂件后缀是".ro"debug版本编译选项使⽤"-D"定义宏debug,使得your code能够执⾏。
Debug怎么解决方案引言在软件开发过程中,经常会遇到各种bug和错误,这时候就需要进行debug(调试)来定位和解决问题。
本文将介绍一些常见的debug解决方案,帮助开发者更高效地调试和解决问题。
1. 确定问题在开始debug之前,首先需要准确定位问题。
了解用户遇到的问题及如何复现可以帮助开发者更快地找到问题所在。
以下是几种确定问题的常用方法:•复现问题:尽量重现用户遇到的问题,并记录重现步骤和环境信息。
这可以帮助开发者更好地理解问题,并在相同的环境中进行调试。
•日志分析:分析应用程序的日志文件,查找错误信息和异常堆栈,以确定问题的来源。
•版本对比:对比出现问题的版本和之前正常工作的版本,查找引入问题的代码变更。
2. 使用调试工具调试工具是开发者解决问题的有力助手,可以帮助定位问题并提供更多的调试信息。
以下是常用的调试工具:•断点调试器:通过在代码中设置断点,在程序执行到断点时暂停,可以逐步调试并查看变量的值、堆栈信息等。
常用的断点调试器有GDB(C/C++)、pdb(Python)、Xcode(iOS)等。
•日志工具:可用于输出调试信息、错误日志和性能统计等。
常见的日志工具有log4j(Java)、log4net(.NET)、NSLog(Objective-C)等。
•性能分析工具:用于检测应用程序的性能瓶颈和优化建议,例如VisualVM(Java)、Instruments(iOS)。
•网络抓包工具:用于分析网络请求和响应,例如Wireshark、Fiddler 等。
可以帮助开发者定位网络相关的问题。
3. 逐步调试逐步调试是一种常用的调试方法,通过逐行或逐块执行代码,观察程序的行为和输出,以定位问题。
以下是逐步调试的步骤:1.设置断点:选择合适的位置,在代码中设置断点。
断点一般设置在问题所在的代码附近,以便观察其执行情况。
2.启动调试:运行调试模式,让程序在断点处暂停执行。
3.逐步执行:逐行或逐块执行代码,观察变量值的变化、函数调用的顺序等。
Debug与Release版本的区别Debug 和Release 并没有本质的区别,他们只是VC预定义提供的两组编译选项的集合,编译器只是按照预定的选项行动。
如果我们愿意,我们完全可以把Debug和Release 的行为完全颠倒过来。
当然也可以提供其他的模式,例如自己定义一组编译选项,然后命名为MY_ABC等。
习惯上,我们仍然更愿意使用VC已经定义好的名称。
Debug版本包括调试信息,所以要比Release版本大很多(可能大数百K至数M)。
至于是否需要DLL支持,主要看你采用的编译选项。
如果是基于A TL的,则Debug和Release 版本对DLL的要求差不多。
如果采用的编译选项为使用MFC动态库,则需要MFC42D.DLL 等库支持,而Release版本需要MFC42.DLL支持。
Release不对源代码进行调试,不考虑MFC的诊断宏,使用的是MFC Release库,编译时对应用程序的速度进行优化,而Debug 则正好相反,它允许对源代码进行调试,可以定义和使用MFC的诊断宏,采用MFC Debug 库,对速度没有优化。
既然Debug和Release仅仅是编译选项的不同,那么为什么要区分Debug和Release 版本呢?Debug和Release,在我看来主要是针对其面向的目标不同的而进行区分的。
Debug通常称为调试版本,通过一系列编译选项的配合,编译的结果通常包含调试信息,而且不做任何优化,以为开发人员提供强大的应用程序调试能力。
而Release通常称为发布版本,是为用户使用的,一般客户不允许在发布版本上进行调试。
所以不保存调试信息,同时,它往往进行了各种优化,以期达到代码最小和速度最优。
为用户的使用提供便利。
下面仅就默认的Debug和Release版本的选项进行比较,详细的编译选项可以看MSDN的说明。
我们将默认的Debug和Release的选项设置进行比较,过滤掉相同设置,主要的不同如下:编译选项:/Od /D "_DEBUG" /Gm /RTC1 /MDd /Fo"Debug““" /ZI链接选项:/OUT:"D:“MyProject“logging“Debug“OptionTest.dll" /INCREMENTAL Release设置:编译选项:/O2 /GL /D "NDEBUG" /FD /MD /Fo"Release““" /Zi链接选项:/OUT:"D:“MyProject“logging“Release“OptionTest.dll" /INCREMENT AL:NODebug 版本:/MDd /MLd 或/MTd 使用Debug runtime library(调试版本的运行时刻函数库) /Od 关闭优化开关/D "_DEBUG" 相当于#define _DEBUG,打开编译调试代码开关(主要针对assert函数)/ZI 创建Edit and continue数据库,在调试过程中如果修改了源代码不需重新编译/GZ 可以帮助捕获内存错误/Gm 打开最小化重链接开关,减少链接时间Release 版本:/MD /ML 或/MT 使用发布版本的运行时刻函数库/O1 或/O2 优化开关,使程序最小或最快/D "NDEBUG" 关闭条件编译调试代码开关(即不编译assert函数)/GF 合并重复的字符串,并将字符串常量放到只读内存,防止被修改MDd与MD首先,Debug版本使用调试版本的运行时库(/MDd选项),Relase版本则使用的是发布版本的运行时库(vcrt.dll)。
代码调试中的常见错误与解决方法代码调试是软件开发过程中不可或缺的一环。
通过调试,开发人员能够找出程序中存在的错误并进行修复,确保程序的正常运行。
然而,调试过程中常常会遇到一些常见的错误。
本文将介绍一些常见的调试错误,并提供相应的解决方法,帮助开发人员快速解决问题。
1. 语法错误语法错误是最常见的错误之一,通常是由于代码中的拼写错误、缺少分号或者括号不匹配等导致的。
在调试过程中,编译器会给出相应的错误提示。
解决方法:- 仔细检查代码,在有错误提示的行进行排查,查看是否有拼写错误、缺少分号等。
- 使用编译器或者集成开发环境(IDE)的语法检查工具,帮助找出语法错误并进行修复。
2. 逻辑错误逻辑错误是指代码的执行结果与预期结果不符合。
这类错误通常由于对程序逻辑的理解不准确或者数据处理错误导致的。
解决方法:- 使用调试工具,在关键的代码处设置断点,并逐步执行代码,观察变量的值是否符合预期。
- 使用日志输出,将关键变量的值输出到日志文件中,以便查看程序执行过程中的数据变化。
- 使用单元测试,编写测试用例来验证程序的逻辑,以便及早发现错误并进行修复。
3. 内存错误内存错误是指程序在使用内存时出现的问题,比如内存泄漏、访问越界等。
这类错误通常会导致程序崩溃或者产生意料之外的结果。
解决方法:- 使用内存调试工具,如Valgrind等,检查程序的内存使用情况,找出内存泄漏或者越界访问的问题。
- 仔细检查代码,查看是否有未释放的内存或者越界访问的情况,并进行修复。
4. 硬件相关错误在某些情况下,代码调试中出现的错误可能与硬件相关。
比如网络连接错误、设备驱动问题等。
解决方法:- 检查硬件设备的连接情况,确保硬件正常工作。
- 检查硬件驱动是否正确安装,更新驱动程序以解决兼容性问题。
- 使用网络调试工具,如Wireshark等,来检查网络连接和数据传输情况。
5. 并发错误并发错误是多线程或多进程程序中常见的问题。
这类错误通常是由于竞争条件、死锁或者资源争夺等引起的。
在编程、调试或测试过程中遇到的问题及解决方法一、问题描述在编程、调试或测试过程中,我们可能会遇到各种各样的问题。
这些问题可能包括语法错误、逻辑错误、性能问题、兼容性问题、数据验证问题等。
这些问题可能会让我们感到困惑和无助,但是请不要担心,通过学习并尝试一些解决方法,这些问题将不再成为我们的障碍。
二、解决方法1. 文档学习:理解代码的每个部分是非常重要的。
每次学习一个新的编程语言或一个新的库时,我们都应该详细阅读文档,理解其工作原理和基本用法。
这可以帮助我们更好地理解和解决问题。
2. 代码审查:通过仔细检查我们的代码,我们可以发现可能被我们忽视的问题。
代码审查不仅可以帮助我们找出问题,还可以提高我们的编程技巧。
3. 调试工具:许多编程环境都提供了强大的调试工具,这些工具可以帮助我们找到代码中的错误。
学习并熟练使用这些工具可以帮助我们更快地解决问题。
4. 社区支持:许多编程社区都提供了友好的支持环境,我们可以向他们寻求帮助,他们通常会提供有用的建议和解决方案。
5. 测试:测试是解决许多编程问题的重要步骤。
通过编写测试用例并运行它们,我们可以发现代码中的错误和不足之处。
6. 版本控制:使用版本控制系统(如Git)可以帮助我们跟踪代码的变化,并快速找到问题的根源。
7. 定期更新:定期更新我们的编程工具和库可以解决因版本过时而导致的问题。
8. 寻求专业建议:当我们遇到复杂的问题时,寻求专业人士的帮助通常是最快和最有效的解决方法。
三、具体案例问题:在编写一个Web应用程序时,我们遇到了性能问题,用户在访问页面时感到缓慢。
解决方法:1. 测试用例:编写一些测试用例来检查应用程序在不同负载下的性能。
2. 调试工具:使用调试工具来检查应用程序的响应时间和资源使用情况。
3. 更新库和工具:尝试更新Web服务器、数据库和其他相关库和工具到最新版本,看是否可以解决问题。
4. 分层架构:考虑使用分层架构来分离不同的功能模块,这可以提高应用程序的性能和可维护性。
代码错误调试:解决代码错误和异常的常见技巧和方法代码错误调试是编程过程中非常常见的一项工作。
当程序运行出现异常或者出现错误时,我们需要采取一些技巧和方法来找到问题并进行修复。
下面是一些常见的解决代码错误和异常的技巧和方法。
1.查看错误信息:当程序出现错误时,通常会有错误信息提示。
这些错误信息可以帮助我们更快地定位问题,了解错误的原因。
因此,首先需要认真查看错误信息,明确问题所在。
2.使用调试器:调试器是一种强大的工具,可以帮助我们逐步执行程序并查看程序在每一步的状态。
通过设置断点、单步调试等功能,我们可以更直观地观察程序运行的过程,找到问题所在。
3.打印调试信息:在程序中适当地插入一些打印语句,输出程序执行过程中的变量值、状态等信息。
通过查看这些信息,可以更清晰地了解程序的执行流程,找到可能出现问题的地方。
4.缩小范围:当程序出现问题时,可以尝试将问题缩小范围,减少程序的复杂度。
例如,可以将程序拆分成几个部分进行分别测试,找出具体出现错误的部分。
5.查看日志:程序通常会有日志输出,记录程序运行的信息和状态。
通过查看日志文件,可以找到程序在哪个地方出现了问题,从而更快定位和解决错误。
6.搜索引擎和社区:在遇到问题时,可以通过搜索引擎和技术社区寻求帮助。
很多时候,别人可能也遇到过相似的问题,通过搜索可以找到解决方法或者相关的讨论。
7.检查语法错误:有些错误是由于语法错误导致的,例如拼写错误、符号错误等。
在遇到问题时,可以先仔细检查程序的语法,确保没有简单的语法错误。
8.更新软件和库:有些错误是由于软件或者库版本不兼容或者存在bug导致的。
在出现问题时,可以尝试更新相关软件和库,查看是否有已知的解决方法。
9.参考文档和教程:在解决问题时,可以参考官方文档和教程,查看相关的使用方法和示例代码。
通过学习文档和教程,我们可以更深入地了解程序的原理和使用方法,更好地解决问题。
10.请教他人:在遇到棘手问题时,可以向他人寻求帮助。
debug怎么解决方案在软件开发的过程中,往往难免会遇到各种各样的bug。
这些bug可能导致程序崩溃、功能失效,甚至引发数据丢失等严重后果。
在解决这些bug的过程中,debug成为了程序员日常工作中必不可少的一环。
本文将探讨debug的一些解决方案,帮助程序员更有效地解决bug。
1. 了解问题首先,要解决一个bug,你需要全面了解问题的本质。
这意味着你需要读懂报错信息,分析代码逻辑,找出潜在的问题所在。
有时候,一个看似微小的错误可能隐藏着更深层次的问题。
因此,不要急于找解决方案,而是要花时间仔细分析问题。
2. 分析代码在找到问题的大致方向后,下一步是分析代码。
你可以使用调试器工具,逐行查看代码执行过程,观察变量的值变化和函数调用的顺序。
这有助于你找到代码中的瑕疵,并定位到具体的错误发生点。
3. 添加日志有时候,bug的解决并不是那么直观。
这时,你可以通过添加日志语句来帮助定位问题。
日志可以记录程序执行过程中的关键信息,帮助你了解程序的内部状态。
通过观察日志输出,你可以更容易地跟踪代码的执行情况,找出问题所在。
4. 编写单元测试单元测试是一种有效的debug手段。
通过编写单元测试,你可以在开发过程中模拟各种情况,测试代码的各个部分。
当你发现某个测试用例失败时,就能快速判断出问题所在,然后修复bug。
同时,单元测试也是一种预防bug的手段,通过及时发现问题,减少bug的出现。
5. 团队合作在大型项目中,debug往往不是一个人独立完成的任务。
团队合作是解决bug的重要方式之一。
团队成员可以互相协作,共同分析问题,提供不同的思路和解决方案。
通过集思广益,可以更快地找到解决方案,并保持高效的开发进度。
6. 查看文档和社区当你遇到困难时,不要忘记查阅文档和参与开发者社区的讨论。
文档通常提供了许多关于特定工具和框架的技术细节和常见问题的解决方法。
此外,开发者社区中有着众多经验丰富的开发者,他们可能已经遇到了类似的问题并找到了解决方案。
代码调试中的常见错误与解决方法在软件开发过程中,代码调试是极为重要的一环。
调试旨在发现并解决代码中的错误,确保程序的正确性和稳定性。
然而,即使是经验丰富的开发人员,在调试过程中也经常会遇到一些常见的错误。
本文将介绍一些常见的代码调试错误,并提供相应的解决方法。
1. 语法错误语法错误是最常见的错误之一。
通常由于拼写错误、缺少分号、括号未正确关闭等原因引起。
要解决语法错误,可以借助集成开发环境(IDE)提供的语法高亮和错误提示功能。
检查代码中的拼写错误,并确保所有的括号都正确关闭。
此外,可以通过代码分块的方式,逐段调试代码,定位语法错误所在的位置。
2. 空指针异常(NullPointerException)空指针异常是在尝试访问“null”对象时引发的错误。
要解决空指针异常,可以使用条件判断语句来检查对象是否为空,然后再对其进行操作。
另外,可以在代码中使用断言来验证对象是否为空,以便及早发现并解决该问题。
3. 数组越界数组越界错误常常发生在试图访问不存在的数组元素时。
要解决数组越界错误,可以通过检查数组索引是否在合法范围内来避免。
可以使用条件判断语句或循环结构来控制数组索引的取值范围。
此外,可以使用调试工具或打印语句来定位引起数组越界的具体代码行,并进行逐行检查。
4. 逻辑错误逻辑错误是一种更为隐蔽的错误,通常导致程序在运行时得到错误的结果。
要解决逻辑错误,可以使用调试工具逐行查看程序的执行过程,查找导致结果错误的原因。
还可以使用日志记录功能,将关键变量的值记录下来,以便分析问题发生的原因。
5. 死循环死循环是指程序在执行某一段代码时陷入无限循环的状态,导致程序无法继续执行下去。
要解决死循环错误,可以使用断点调试工具在循环的关键位置设置断点,然后逐步执行代码,观察循环变量的变化。
此外,可以使用循环条件来限制循环次数,避免无限循环的发生。
6. 慢速调试慢速调试是指调试过程中程序执行速度过慢的问题。
要解决慢速调试的问题,可以尝试优化代码,减少不必要的计算和函数调用。
调试过程的问题及解决方法调试是软件开发过程中不可或缺的一环,它用于查找和修复代码中的错误。
然而,在调试过程中常常会遇到各种问题,下面将讨论一些常见的调试问题及其解决方法。
1. 编译错误:编译错误是最常见的问题之一。
当编译器无法正确解析代码时,会产生编译错误。
解决方法包括检查语法错误、缺少的依赖项以及命名冲突等。
编译器通常会提供错误消息和行号,有助于定位问题所在。
2. 运行时错误:运行时错误是在程序执行过程中发生的错误。
常见的运行时错误包括空指针引用、数组越界和除以零等。
解决方法包括使用调试器逐行跟踪程序执行过程、检查变量的值和程序流程等。
调试器可以帮助开发人员定位错误发生的位置和原因。
3. 逻辑错误:逻辑错误是代码中的错误逻辑或算法导致程序运行不正确的问题。
解决方法包括仔细检查代码逻辑、使用调试器观察变量值和程序流程、添加日志输出等。
通过仔细分析代码,可以找到导致逻辑错误的原因,并进行相应的修复。
4. 环境配置问题:有时调试过程中遇到的问题可能与环境配置有关。
例如,缺少必要的库文件或配置不正确。
解决方法包括仔细检查环境配置、确保所需的库文件已正确安装和链接等。
5. 多线程问题:多线程编程中的问题可能难以调试,因为线程之间的交互和竞态条件可能导致不确定的结果。
解决方法包括使用调试器观察线程的执行和相互作用、添加同步机制以避免竞态条件等。
6. 调试工具问题:有时候调试工具本身可能出现问题,例如崩溃或无法正常启动。
解决方法包括重新安装或升级调试工具、查找并修复相关错误报告等。
总结来说,在调试过程中遇到问题时,需要耐心和仔细地分析代码和错误信息,使用适当的调试技术和工具来定位和解决问题。
同时,编写可调试性强的代码和添加适当的日志输出也是预防和解决调试问题的有效手段。
[release][版本][调试]release版本下调试正常运行exe出错 - VC/MFC / 基础类10月 9th, 2010 by adminPosted in VC/MFC | No Comments »我做的一个调用dll的程序,在debug下调试和运行exe都正常在release下调试也正常,但是直接运行release下的exe就会挂掉,请高人指点一下,到底是什么原因。
程序中有调用外部工具执行解压和压缩,因为没有使用多线程,在解压缩的时候会使主框架无响应,在这样的状态下进入调用dll的模块,然后程序执行一半就挂掉了,是不是和解压缩有关呢 ?不会是跟路径有关吧?程序中使用的相对路径???跟路径无关,都是相对路径而且release下调试是通过的,能正常运行得出结果但是,直接执行release下的exe文件就挂掉了,很奇怪运行就挂掉是指,没有响应?程序崩溃?程序直接消失?没有响应的话,是某个地方阻塞掉了,可以根据程序流程来跟踪,看执行到哪里才没响应的.程序崩溃的话,看看提示是什么,再跟踪程序流程.程序直接消失的话,多半是栈溢出了.挂掉的时候attach process一下,再查看堆栈,可以定位出在哪个函数挂掉了。
<<很可能就是路径的问题release调试的时候,可以设置工作目录,其他相对路径都是基于这个工作目录release运行的时候,工作目录应该是其所在的文件夹用几个messagebox调试的看看一定是路径问题!把dll放到release一份看看。
把dll放到release 目录下,再直接运行exe文件试试.- - 路径不正确吧。
一些指针变量未初始化??字节对齐方式不对??在PostMessage或者在SendMessage处查看,我也碰到这问题,就是这么解决的.80%是相对路径,改成绝对路径试试有没有考虑过权限的问题,调试的时候程序是有DEBUG权限的,直接运行是没有这么高的权限+看下库依赖问题 depends<顶一个!<Tags: , release, 版本, 调试[release][版本][VC/MFC]急!!~~release版本出现问题 - VC/MFC / 基础类09月 17th, 2010 by adminPosted in VC/MFC | No Comments »本人的聊天程序在debug的版本下可以顺利发送和接收对方聊天消息,但是在release版本下却出现了严重问题,症状如下:第一次发送消息,对方能正常接收并显示,当第二次发送消息对方接收到消息后,也能显示,但接着程序就出错,按“调试”按钮后就进入一个汇编代码文件,按F5往下运行就弹出“无效的句柄”对话框。
我现在不知该如何对release版本进行调试,只猜测问题可能出在以下函数中的ReceiveFrom():UINT CUUClientDlg::ChatRecvListening(LPVOID pParam)//等待接收对方消息的多线程处理函数{CUUClientDlg* pDlg=(CUUClientDlg*)(AfxGetApp()-> m_pMainWnd); CChatSocket* pSock=new CChatSocket(pDlg);SOCKET* phSocket =(SOCKET *)pParam;CString str;pSock-> Attach(*phSocket);int len;while(1){len=pSock-> ReceiveFrom(&buf,sizeof(buf),strIP,nPort,0);if(len==SOCKET_ERROR){int error;error=pSock-> GetLastError();return FALSE;}::SendMessage(pDlg-> GetSafeHwnd(),WM_RECV_CHATMSG,0,0);}return TRUE;}有无特殊的设置检查下和Debug版有何不同咯::SendMessage()改成PostMessage()试下。
终于找到原因,原来是自定义消息的问题。
自定义消息的消息参数。
MFC为我们提供了很好的消息机制,更增加了自定义消息,好处我就不用多说了。
这也存在debug跟release的问题吗?答案是肯定的。
在自定义消息的函数体声明时,时常会看到这样的写法:afx_msg LRESULT OnMessageOwn(); Debug情况下一般不会有任何问题,而当你在Release下且多线程或进程间使用了消息传递时就会导致无效句柄之类的错误。
导致这个错误直接原因是消息体的参数没有添加,即应该写成:afx_msg LRESULT OnMessageOwn(WPARAM wparam, LPARAM lparam);非常感谢这篇文章的解析/article/17/17068.shtm我晕,你定义消息响应函数都不带参数。
强。
别晕~~毕竟,我是第一次使用自定义消息,我以为只要格式对了,就可以了,怎么连参数也一定要带呢,尽管我的响应函数不需要参数。
MARKTags: , release, VC/MFC, 版本[VC2008][生成][Release]VC2008生成Release版本选择优化选项后居然把我整个函数给跳过了 -VC/MFC / 进程/线程/DLL09月 11th, 2010 by adminPosted in VC/MFC | No Comments »我有一个函数,不是内联的。
在打开编译优化选项后,居然整个函数给我跳过了。
我用MessageBox放在这个函数内部作测试的,Debug版本下正常,到了Release版怎么也进不了这个函数,生成调试信息后单步跟踪发现直接就跳过去了。
对话框也没跳出来。
禁用编译优化选项后一切正常了,这种问题怎么回事?是不是你的函数没什么用处啊?比如 void myfun(){ int a=10;}这样可能被优化掉代码里怎么写的呢?<<如果是没用的函数,就是会被优化掉。
不如你检查一下那个地方的代码吧,是不是有判断条件啊什么的有问题。
那应该是编译器认为你要调用的函数需要优化,而优化之后也有可能把这部分代码给隔离掉,区分优化和不优化的代码。
所以它不进来?我只是个人观点,你可以去google下。
如果始终在那里跳过,但你的程序运行仍然正常的话,是不是可以说明在该处调用这个函数无意义呢?<我还仔细检查过函数内部的判断条件,没有哪种情况它不应该执行的你先把Debug目录清空删除,再重新编译Debug版,看看是不是还正常???<不对,看错了,现在Debug版本错误更多。
禁用优化以后又正常了诡异。
换个编译器试试吧函数没有输出,当然会被优化掉。
<<这个可能要抠具体的优化选项了权宜之计是针对这一部分代码禁用优化 <<就冲你这态度,你解决不了这个问题,就算侥幸绕过这个问题,你早晚还会栽在上面。
Tags: , release, vc2008, 生成[release][调试][VC/MFC]release 能调试吗 -VC/MFC / 基础类08月 30th, 2010 by adminPosted in VC/MFC | No Comments »我在公司看见有人写的代码全是在release下调试的,debug下全部是异常,程序直接崩溃,然后他们问我干嘛要用debug,我无言以对了,他们拷贝字符串都是这样的:void copystr(char * pIn){int len = strlen(pIn);char * p = new char[len];strcpy(p,pIn);}呵呵,我们公司因为工程大,好多人都是release带DEbug信息调试编码的。
不我还建议用debug比较好,因为Release回忽略掉一些小问题的。
你才crash的时候点击“重试”,看一下callstack把这些问题一一修正给他们弄一个debug环境。
如果你公司的人来我这里应聘程序员,我会让他们统统去扫厕所。
void copystr(char * pIn){int len = strlen(pIn);char * p = new char[len];strcpy(p,pIn);}这个函数也能用吗晕,路过release可以调试是不假不过不建议使用除非迫不得已因为确实有些问题bug下调不出来release状态下可以调试的release和debug只是编译参数不同而已,你也可以命名自己的编译设置具体设置参考:/baicker/archive/2007/08/29/140713.html———————————————————————————<能调试,但是个别变量可能无法对应,有些只能看内存<<release 调试有时候鼠标放那,看不到结果。
基本debug调。
release走一遍主要是我改成DEBUG运行不了,全是runtime error,不能执行,他们叫我直接忽略最最无奈的是100多个工程全是这样的,而且那几个写代码的人同时辞职了你们公司的人的态度真另人受不了<<无语!有些大部分是没有经过专门学习的半路程序员,只求功能实现,其他代码规范,一律不管,我见得不少,如果你们想知道更牛逼的,我知道在一个正规的项目中有一个这样的类命名:int n1,n2,nxxx,xxx到200多变量int j1,j2 jxxx,xxx到100多,下面还用这些变量,完全是小学生作业;我看了全删了重写的命名变量<release 都有优化怎么调试?建议 Release 使用LOG来“调试”LINK : fatal error LNK1181: cannot open input file ";/out:Release/Chinese.exe" 试着用Release来调试,但提示这个错误,是怎么回事?Tags: , release, VC/MFC, 调试[release][调试][VC/MFC]release 能调试吗 -VC/MFC / 基础类08月 29th, 2010 by adminPosted in VC/MFC | No Comments »我在公司看见有人写的代码全是在release下调试的,debug下全部是异常,程序直接崩溃,然后他们问我干嘛要用debug,我无言以对了,他们拷贝字符串都是这样的:void copystr(char * pIn){int len = strlen(pIn);char * p = new char[len];strcpy(p,pIn);}呵呵,我们公司因为工程大,好多人都是release带DEbug信息调试编码的。