编译策略介绍 关于优化级别:GCC_OPTIMIZATION_LEVEL 描述如下 None: Do not optimize.  [-O0]With this setting, the compiler’s goal is to reduce the cost of compilation and to make debugging produce the expected results. Statements are independent: if you stop the program

我们经常会使用条件编译符 #if DEBUG 在 Debug 下执行某些特殊代码.但是一旦我们把代码打包成 dll,然后发布给其他小伙伴使用的时候,这样的判断就失效了,因为发布的库是 Release 配置的:那些 #if DEBUG 的代码根本都不会编译进库中.然而总有时候希望在库中也能得知程序是 Debug 还是 Release,以便库发布之后也能在 Debug 下多做一些检查. 那么有办法得知使用此库的程序是 Debug 配置还是 Release 配置下编译的呢?本文将介绍一个比较靠谱的方法

一.Debug 和 Release 编译方式的本质区别 Debug 通常称为调试版本,它包含调试信息,并且不作任何优化,便于程序员调试程序.Release 称为发布版本,它往往是进行了各种优化,使得程序在代码大小和运行速度上都是最优的,以便用户很好地使用. Debug 和 Release 的真正秘密,在于一组编译选项.下面列出了分别针对二者的选项(当然除此之外还有其他一些,如/Fd /Fo,但区别并不重要,通常他们也不会引起 Release 版错误,在此不讨论). Debug 版本: /MDd 

一般在安装时提示出错:INSTALL_PARSE_FAILED_INCONSISTENT_CERTIFICATES 1) 两个应用,名字相同,签名不同 2) 升级时前一版本签名,后一版本没签名 3) 升级时前一版本为DEBUG签名,后一个为自定义签名 4) 升级时前一版本为Android源码中的签 1 查看默认签名 不同的机子上或不同的设备上,利用eclipse编译出的apk签名是不一样的.eclipse都有一个默认的签名.查看签名路径: 1)打开Eclipse->Preferences->A

VS中的程序有两种编译模式:Debug模式和Release模式. Debug通常称为调试版本,通过一系列编译选项的配合,编译结果通常包含调试信息,而且不做任何优化,以为开发人员提供强大的应用程序调试能力. Release通常称为发布版本,是为用户使用的,一般客户不允许在发布版本上进行调试,所以不保存调试信息,同时它往往进行了各种优化,以期达到代码最小和速度最优,为用户的使用提供便利. Debug程序通常要比Releas程序要慢,尤其是处理视频方面Release要比Debug快很多,在Releas

自己在debug下成功运行了自己写的测试自己写第三方库的程序,这里有用到opencv库,所以同时用到了自己的库和opencv的库,需求因为要进行速度的测试,是想要把debug改成release版本,这里出现了错误改了一天,终于搞定. 这里遇到的错误及解决方法如下: 问题一:出现如下所示错误. 问题二:错误 77 error C1189: #error : Please use the /MD switch for _AFXDLL builds     C:\Program Files (x86)

1.Debug模式和Release模式 在vs中,运行程序有两种模式:Debug和Release 在bin目录下也会生成对应的文件夹,用于存放生成的dll等文件,这两种模式的区别如下: Debug:用全部符号调试信息编译,不进行优化(优化会使调试复杂化,因为源代码和生成的指令间的关系更加复杂). Release:被完全优化,不包含任何符号调试信息.调试信息可在单独的pdb文件中生成 上面两种模式生成的dll的文件大小不一样 Debug模式:Release模式:(因为进行了符号的优化) 2.项目文

Visual Studio 项目对程序的发布和调试版本分别有单独的配置.顾名思义,生成调试版本的目的是用于调试,而生成发布版本的目的是用于版本的最终分发. 如果在 Visual Studio 中创建程序,Visual Studio 将自动创建这些配置并设置适当的默认选项和其他设置.在默认设置下: 程序的“调试”配置用全部符号调试信息编译,不进行优化.(优化会使调试复杂化,因为源代码和生成的指令间的关系更加复杂.) 程序的“发布”配置被完全优化,不包含任何符号调试信息.调试信息可在单独的 PDB

原文地址:http://blog.csdn.net/itwit/article/details/6803338 今天写程序的时候,需要更改.exe.config文件中的引用的webservice地址,用vs调试的时候,发现会修改vshost.exe.config中的对应项,.exe.config中的对应项是不会修改的,这样会导致在软件重启的情况下,.exe.config中的旧信息会覆盖vshost.exe.config的新信息,经过查阅相关资料,终于明白了一些,记录下来,供参考~ 1.vshos

好久没有做web项目了,这项目完成了要发布网站,不好忘了 以前操作过的? 还好脑子还是有点印象 现还是 写个文档吧记录吧 免得 以后作别的了又忘了 那可不妙啊 网站发布步骤:1.先将

Debug版本:通常称为调试版本,它包含调试信息,并且不作任何优化,便于程序员调试程序. Release版本:称为发布版本,它往往是进行了各种优化,使得程序在代码大小和运行速度上都是最优的,以便用户很好地使用. 实际上,Debug版本和 Release 并没有本质的界限,他们只是一组编译选项的集合,编译器只是按照预定的选项行动.事实上,我们甚至可以修改这些选项,从而得到优化过的调试版本或是带跟踪语句的发布版本. 在Debug或Release文件夹中,通常会看到几种类型的文件: 1.应用程序扩展类

这篇文章解释了如何使用驱动程序验证工具来分析崩溃转储文件. 使用Microsoft驱动程序验证工具 如果您曾经使用Windows的调试工具来分析崩溃转储,那么毫无疑问,您已经使用WinDbg打开了一个崩溃转储文件.WinDbg将对崩溃文件执行内部分析,并建议您从!analyze命令开始.该命令输出堆栈以及许多其他信息.执行此操作时,堆栈底部将显示转换为内核模式的线程,然后从那里开始,您向上遍历堆栈以查看是否存在罪魁祸首驱动程序.虽然这是一种可靠的调试技术,但有时崩溃转储或其中的一组将无法分析.内

Author: Maddock Date: 2015-03-26 09:34:48 问题来源:http://bbs.csdn.net/topics/390733725 PS: 按照上述方法做的时候,在debug和release界面的附加依赖项里其中一个编辑完,另一个为什么也出现了和其一样的附加依赖项?怎么实现debug和release中的附加依赖项不一样?? 哪位大侠知道解决方法,求告知!!!!! 在VS下面,opencv的debug和release版本需要不同的lib版本,在debug版本和r

服务器程序DEBUG 服务器端设定 Tomcat 默认我们启动Tomcat是使用下边的命令 ./catalina.sh start 如果想DEBUG的话,只需要加一个参数打开JPDA(Java Platform Debugger Architecture)就可以了 ./catalina.sh jpda start 注:默认的监听端口是8000,如果想修改这个端口的话,可以修改环境变量JPDAADDRESS. 如果我们的服务器是通过daemon.sh启动的tomcat话,貌似没有找到默认打开JPD

获取debug.keystore的key,如下图 获取release.keystore的key 输入命令keytool -list -v -keystore <jksFilename> 例如keytool -list -v -keystore BuIsh.jks,执行 便可得到key 参考博文:快速获取debug.keystore和release.keystore的SHA1或者MD5值

编译debug版本或release 版本 在Run和Stop按钮的右边有一个工程名 点击工程名,选择Manage Schemes 选择Edit... 左侧选择Run ProjectName.app 右侧选择Info页,在Build Configuraion选择相对应你需要生成的版本就行了.   编译完成后,选择XCode的File菜单里面的Project Settings...然后就会出现生成目录...

今天修改了以前一个项目的代码,是一个exe程序  C++ builder xe2 编译.以前都是好的.今天改了一下版本号 编译了一下,居然不能用了.直接崩溃 提示内存非法访问.而且显然还没有进入WinMain就崩溃了,这种一般是最不好调试的.用OD调试了半天也没有看出个所以然.检查了一下最近改过的代码,都没有发现问题. 之后改为Debug版本直接单步执行发现没有问题.所以继续执行也没有问题.索性直接运行也没有问题.操蛋原来Debug是好的.百思不得其解,看了看相关_DEBUG宏的代码也没有什么问

在开发过程中,我们经常需要用到NSLog输出一些信息,甚至有的开发过程,必须在控制台查看输出,有经验的程序员通过控制台输出就能知道整个数据交互的一个流程.但是一个发布的程序,里面带有太多的NSLog输出,肯定对于App性能有所影响,这时候我们可以使用一个宏定义来处理,在开发的时候使用DEBUG模式,在发布的时候使用RELEASE模式.这样,发布的App就不会在程序内部做大量的NSLog输出了. 简单的代码如下, #if defined(DEBUG)||defined(_DEBUG) NSLog(

有时候,所见并不是所得,有些包,你需要去翻他的源码才知道为什么会这样. 背景 今天调试一个程序,用到了一个很久之前的NPM包,名为formstream,用来将form表单数据转换为流的形式进行接口调用时的数据传递. 这是一个几年前的项目,所以使用的是Generator+co实现的异步流程. 其中有这样一个功能,从某处获取一些图片URL,并将URL以及一些其他的常规参数组装到一起,调用另外的一个服务,将数据发送过去. 大致是这样的代码: const co = require('co') const

删掉程序默认的main.storyboard文件后,程序启动崩溃 如图所示.原因是删掉main.storyboard文件后没有在info.plist文件里面设置 删掉main.storyboard后程序启动变黑 原因是:虽然删掉main.storyboard并且在info.plist文件中设置了,但是并没有指定程序启动后的根控制器即: window.rootViewController所以启动后是黑色的屏幕,设置需要在Appdelegate.m中设置如图: 这样启动后默认就是白色,PBViewC

我所用的系统环境是Win7 32位操作系统+VS2010编译环境.所以在debug模式下调通之后,在Release模式下调试不通过,最后通过上网查资料和自己对比两个编译选项得出以下结论: 修改“项目->属性->配置属性->C/C++->优化”中的优化选项从使速度最大化(/O2)修改为已禁用(/Od). 修改“项目->属性->配置属性->链接器->优化”中的优化选项从使是(/OPT:REF)改为<从父级或者项目默认设置继承>.