windowsVS编译器各种错误

一、出现类似于error C4996: ‘scanf’: This function or variable may be unsafe的安全检查错误

用习惯了VS老版本的人当刚使用VS2013的时候可能总遇到类似于这样的错误：

error C4996: 'scanf': This function or variable may be unsafe. Consider using scanf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.

这个问题一般使用以下几种解决办法：

（1）scanf等类似的函数已经不太安全，要想保证程序的安全性，建议以后采用_s结尾的安全版本，但是很多以前的程序可能还是使用不安全的版本，那么下面给出去掉这种错误提示的几种办法。

（2）在VS中新建项目的时候去掉“安全开发生命周期(SDL)检查”即可将错误转变成警告，使得使用不安全版本也不影响编译和运行，如下图所示。

或在项目属性中取消安全开发生命周期(SDL)检查，如图所示：

（3）在头文件包含的最前面，记住是最前面（在include的前面）加上：#define _CRT_SECURE_NO_WARNINGS这个宏定义即可，如下图所示。

（4）在编译的头文件最前面加上：#pragma warning( disable : 4996)即可，类似于上图，此处不再附图。

（5）通过以下步骤Project properties->Configuration Properties->C/C+±>Preprocessor->Preprocessor Definitions进入到预处理的定义中，点击按钮 (…)，输入：_CRT_SECURE_NO_WARNINGS，使用 “\n” 相隔即可。

总之，如果想完全不做安全检查，就使用（2）中的方法或者（5）中的方法，如果只是对某些文件不使用，可以使用（3）和（4）中的方法，个人喜欢使用（2）中的方法，大家可以根据按需选择，不过随着安全性的重要程度在逐步提高，还是建议大家以后使用安全版本。

二、expression:stream!=NULL
如果fopen（）后返回的是NULL；就不能调用fclose（）了；

用fopen()获得的文件句柄不是NULL，那么就需要用fclose()来关闭它。如果是NULL则不需要

null就表示你打开文件失败了，根本都没有成功的访问文件，也就不存在对数据有什么损坏的可能。不需要关闭

三、出现异常“… \debug_heap.cpp Line:980 Expression:__acrt_first_block==header"

!

File: minkernel\crts\ucrt\src\appcrt\heap\debug_heap.cpp
Line: 980
Expression: __acrt_first_block == header
For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.

方案一：
如果使用vector<vector > contours;作为findContours的参数，在运行时会得到
Assertion failed (mtype == type0 || (CV_MAT_CN(mtype) == CV_MAT_CN(type0) && ((1 << type0) & f…
原因是标准库里有std::vector 和 Point 和findContours里要用到的vector和Point不是一回事所以，声明的时候要用cv::vector和cv::Point就可以了。

方案二：
“修改了当前程序的vc运行库配置，问题解决。具体方法是：项目-属性-配置属性-C/C+±代码生成-运行库，将其改为“多线程调试(/MTd)”。”

方案三：
在配置属性->常规->MFC的使用中，将在静态库中使用MFC改为在共享DLL中使用MFC。

方案四：
将程序改为：

vector contours(100);
Mat hierarchy;
findContours( BW, contours, hierarchy, CV_RETR_CCOMP, CV_CHAIN_APPROX_NONE );

方案五：
当一个DLL采用静态的方式链接到C运行时库时，会创建一个相对于该DLL的堆(Heap)，而如果采用共享的方式链接到C运行时库的时候则使用的是应用程序的堆内存。而_CrtIsValidHeapPointer()在 DEBug模式下将确保传入的地址在本地的堆内存中。 因此就有理由相信，真有可能是静态链接的问题。所以，我立即尝试将：
项目–属性–配置属性–常规–MFC的使用– 选择在共享DLL中使用MFC ；同时，
项目–属性–配置属性–C/C++–代码生成–运行库–选择 多线程DLL(/MD)或MDd。

错误分析：__acrt_first_block == header可以大致的知道是堆内存出现的问题，堆区一般都是用来申请分配动态数组时才会使用，而申请动态数组用的最多的就是使用关键字new[]进行申请分配。而我在程序中并未使用new，哪来的堆区的使用呢，通过查找资料了解到vector可以动态分配内存，因此问题极可能就出现在这上面。通过查阅资料了解到是vector析构异常导致的问题，可以借鉴这篇文章看一下http://www.aiuxian.com/article/p-1722238.html。原文部分如下：
大概是因为 dll 如果静态链接了运行时库，dll 就会拥有独立于应用程序堆（也称作local heap）的运行时堆实例。此时在 dll 外部就不能访问此 local heap，所以也就有上面所出现的异常啦。MSDN 中也有介绍：
　　The _CrtIsValidHeapPointer function is used to ensure that a specific memory address is within the local heap. The local heap refers to the heap created and managed by a particular instance of the C run-time library. If a dynamic-link library (DLL) contains a static link to the run-time library, it has its own instance of the run-time heap, and therefore its own heap, independent of the application’s local heap. When _DEBUG is not defined, calls to _CrtIsValidHeapPointer are removed during preprocessing.
程序崩溃在当析构一个带有vector成员函数对象的时候，在析构vector时，会出现这个错误，大致原因是因为析构的时候找不到vector分配的空间。
一行一行查看代码发现，对象里面的points2, status等vector变量是在calcOpticalFlowPyrLK(img1, img2, points1, points2, status, similarity, window_size, level, term_criteria, lambda, 0); 函数中分配的，即opencv的dll，所以当对象进行析构的时候，因为不能访问此local heap所以会有异常崩溃。

待更新。。