编译过的Release版的opencv库，可以直接调用，已经测试过，支持vs2013,vs2015，vs2017。

OpenCV 3.2.0 移植到ARM所需要的第三方库包，OpenCV交叉编译工具链。包括(zlib-1.2.8.tar.gz、yasm-1.3.0.tar.gz、xvidcore_1.3.3.orig.tar.gz、libpng-1.6.32.tar.xz、last_x264.tar.bz2、jpegsrc.v9b.tar.gz、ffmpeg-3.4.tar.bz2、arm-linux-gcc-4.4.3.tar.gz)

已经完全编译好的opencv，只需要将相关的dll文件等添加进vs配置表即可。

opencv3.4.11编译过程使用的库以及编译完成的opencv3.4.11,添加了opencv_ffmpeg.dll、 opencv_ffmpeg_64.dll等库

编译完成的opencv3.4.11库

opencv_python-3.4.1+contrib-cp36-cp36m-win_amd64.whl opencv3.41 包含了opencv 4 没有的 haarcascade_mcs_mouth.xml,contrib配合opencv3.41使用，opencv3.41可到www.opencv.org 去下载

opencv3.4.3+vs2017+opencv_contrib3.4.3+cmake后的文件部分 不用再辛辛苦苦cmake了 直接下载后配置环境就好了

虽然opencv可以直接在官网上下载，但是很坑的是opencv3居然不能直接用surf特征检测，之前需要一系列的准本工作，所以分享了这个压缩包可以直接使用

17.2　垃圾回收机制 在C++中，对象的删除是由程序员负责的，可以使用delete关键字来执行这一操作。如 果程序员忘记删除对象，则可能出现内存泄露（memory leak）的问题，包括未释放内存， 访问未分配的内存区域，访问不存在的对象等。这些问题经常又很难重现，在调试时需要花 费很多的时间去追踪。 在.NET中，为了将开发人员从内存管理的繁琐过程中解脱出来，将更多的精力用在业务 逻辑上，CLR提供了自动执行垃圾回收的机制来进行内存管理，开发人员甚至感觉不到这一 过程的存在。CLR执行垃圾回收的过程，有几个要点，这也是本章的主要内容： ❑如何判断哪些对象是可以进行回收的，哪些是要保留的？ ❑对象在堆上是如何分布的？何时执行垃圾回收？ ❑垃圾回收的过程是如何进行的？有哪些优化策略？ 17.2.1　判断哪些对象需要进行回收 执行垃圾回收，要解决的第一个问题就是判断哪些对象需要被垃圾回收。 现在再回到本书17.1的例子，继续关注没有任何变量引用到的Phone对象。如果它继续 停留在托管堆上，那么势必要持续地占用内存资源。如果程序中存在大量创建对象的代码， 例如创建一个成员很多的数组，占用的内存资源会更多。因此，需要进行垃圾回收的对象就 是：在代码中的任何位置也无法访问到的对象。 那么如何判断哪些对象能够被访问，哪些对象无法被访问呢？CLR需要借助于应用程序 根（Application Roots）和对象图（Object Graph）。应用程序根保存了对堆上对象的引 用，因此，上面RunTest()方法中的item变量，即是应用程序根的一种。如果一个对象没有 直接或间接被应用程序根所引用，那么就说明没有任何代码可以访问到它，因此这个对象可 以被回收。应用程序根有下面几种：

我也没办法啊，不能设置为免费产品哦，所以就随便设置一个分数吧 随便下载吧 是最新版本哦