之前分享过一篇关于 cmake 的入门文章:《使用 cmake 来搭建跨平台的应用程序框架:C语言版本》,那篇文章重点是描述如何利用 cmake 来编译或者构建跨平台的工程,并没有涉及到团队协作开发方面的内容。
通常在程序设计中采用xml、ini、yaml、json等配置文件比较多。在Java的SpringBoot项目中通常采用yaml或者yml文件作为应用的配置项。由于本人在实际项目中采用C++编写控制台程序的过程中使用yaml文件比较多,目前使用比较的多的就是yaml-cpp这个C++ yaml解析库了。之前写过两篇关于在CentOS7下编译yaml-cpp库和Windows10下使用VS2017编译和使用yaml-cpp库的文章。 最近实际项目中换成了最新版的Visual Studio 2019,我使用的Windows系统是Win7和Windows10,所以需要重新编译基于VS2019下的yaml-cpp的Debug和Release版本的Win32的静态lib库,大体步骤和Windows10下使用VS2017编译和使用yaml-cpp库这篇博客描述的一致。
参考前文 windows 10安装CUDA和cuDNN,地址是:https://xugaoxiang.com/2019/12/18/windows-10-cuda-cudnn/, 这里不再赘述。
配置该环境主要是配合 Android 进行开发 , 目前 Android 中调用 C/C++ 代码使用的都是 CMake 构建项目 , 因此在次数 VS 中要使用 CMake 构建 FFMPEG 的开发环境 ;
mingw(gcc)编译出来的动态库(DLL)默认是没有MSVC连接动态库所需要的lib文件(import library)的。
使用ctkPluginFramework作为插件系统框架的确有着众多开发上的优势。最近收到一些站内信,大家都想使用ctkPluginFramework但是不知道如何编译,这篇教程就来讲一讲ctkPluginFramework插件系统在Windows下的编译过程。
博客源码下载地址 : https://download.csdn.net/download/han1202012/87358942
Java中有很多日志库:java.util.logging、Log4j、Logback、Log4j2、slf4j、common-logging。C++的日志库相对来说就比较少了,比如说glog、log4cpp、spdllog等,目前个人感觉比较好用的C++开源日志库当属于spdlog了,跨平台,支持cmake编译,在维护中。 具体可以参考github上面的示例:https://github.com/gabime/spdlog 另外spdlog支持两种使用方式:一种是将源代码目录下的include头文件直接添加到自己的项目中使用;另一种使用cmake编译构建出lib静态库或者dll动态库之后以静态和动态链接方式使用。
log4cplus是C++编写的开源的日志系统,前身是java编写的log4j系统,受Apache Software License保护,作者是Tad E. Smith。
按照以前的经验,编译Tesseract 3.05就是去GitHub上找一个已经解决了依赖关系(如Leptonica等)的VS2015解决方案,然后在VS中编译生成?是不是最痛苦的地方就是找不到这样的解决方案,或者在自己的Windows中不能正常编译?
填一个之前的坑啊,本篇的姊妹篇——利用Pytorch的C++前端(libtorch)读取预训练权重并进行预测 这篇文章中已经说明了如何在Ubuntu系统中使用libtorch做预测,当初也有朋友问我如何在Windows之下尝试使用libtorch,当时因为时间关系没有去看,后来就给忘了…现在有时间了当然要尝试一下~
更新于2019/10/22 20:16 有同学反馈说运行报错,笔者刚试了下,下载源码,然后通过Cmake编译,然后用VS2017运行没有问题。 在VS2017 15.9.10编译好的文件 /bin目录 笔者的 VS 版本是 VS2017 15.9.10 企业版 下载链接, 建议下载相同的版本。
Visual Studio 2022 正式版于发布。新版本带有 go-live 许可证,可供生产使用。在 Visual Studio 2019 的基础上,新版集成开发坏境提供了非常多的改进,包括对 64 位、.NET 6 和 C++ 20 的支持,为核心调试器提供更好的性能,并在实时共享会话中支持文本聊天。
在同样的位置右键单击“源文件”,选择“添加现有项”,并选择 SFML-2.5.1/lib 目录下与编译器相匹配的所有库文件(.lib 或 .a)。例如,如果你使用的是 64 位的编译器,就应该添加 SFML-2.5.1/lib/x64 下的所有库文件。
Clangen使用 ClangSharp解析头文件来完成一些中间代码的生成(如Rpc的注册代码, 桩代码, C++类导出到Lua的代码等). 而ClangSharp本身依赖了llvm, 以及自己的一个libClangSharp的库, windows和linux下需要编译一下llvm和这个库, 一般来说系统没变的情况下, 直接使用已经编译好的libclang.so/dll即可, 但有些时候遇到需要升级llvm到高版本的情况, 比如说我们之前碰到的情况 , llvm9在linux下运行速度异常(Windows下10S的流程, 在linux下处理同样的任务要快3分钟, 最后发现可能之前编译使用的是debug版本), 我们需要编译LLVM, 并且编译依赖llvm的libClangSharp, 官方文件比较简单, 而且配置项有一些问题, 可能导致不能正常编译, 所以这里记录下过程方便后续有相关需求的时候可以参照处理.
最近在做一个工业巡检的项目,主要涉及的内容是指针型表计的读取。本系列文章主要介绍实现表计读取的全流程开发(立个FLAG,想想真是肝...留下了不争气的眼泪),其中主要使用的工具为百度开发的PaddleX和Visual studio 2019。
打开 Visual Studio 2019 , 在 VS 欢迎界面中 , 选择 " 创建新项目 " 选项 ,
BareSIP是开源的SIP协议栈,我们可以基于BareSIP开发软电话应用。我们可以在项目中直接引入BareSIP的库,也可以将BareSIP的源代码引入到项目中,目前BareSIP还不是很稳定,因此,使用后者的方式方便我们对BareSIP进行二次开发以及修改问题。
1 . JNI 简介 : JNI 是一套框架 , 能够让开发者在 Java 中调用 C / C++ 代码 , JNI 范围较广 , 凡是可以运行 Java 代码的地方 ( 如 Linux , UNIX , Windows , Android 等平台 ) , 都可以通过 JNI 接口 调用 C/C++ 代码 ;
关于OCR这块以前《Android通过OpenCV和TesserartOCR实时进行识别》中用过TesserartOCR,原来用的模型库也挺大,最近也研究了下别的OCR,最终决定采用百度飞桨PaddleOCR,本篇就是基于百度飞桨的PaddleOCR在Window版下C++的布署。
再介绍一个谷歌的,自带光环的库–libphonenumber. 虽然这个库是用c++写的,但是我们在网络上很少见到在C++开发中使用这个库,或是说在windows开发中使用这个库。也就是几乎很难找到如何编译libphonenumber.lib 和 libphonenumber.dll. 所以,今天就要与大家分享一下,如何编译libphonenumber.lib,以及简单的使用。 libphonenumber简介 phonenumber是用于解析、格式化、存储和校验电话号码的Java、C++或 JavaScr
前不久,微软正式发布了 Visual Studio 2022,Visual Studio 2022 的主要功能包括:
本文介绍在Visual Studio软件中配置、编译C++环境下GDAL库、SQLite环境与PROJ库的详细方法。
近来由于需要用到 opencv 的SIFT特征,但是SIFT等功能已经移入了opencv_contrib 中,所以需要重新编译opencv和opencv_contrib。
版权声明:本文为博主原创文章,转载请注明源地址。 https://blog.csdn.net/10km/article/details/51735432
QT的项目工程默认使用的是qmake,这本来也没什么问题。但是由于要用到vcpkg这个工具来管理第三方库,好像这个 vcpkg工具只能在cmake的项目中才能使用。
大家好,又见面了,我是你们的朋友全栈君。 JRTPLib的编译步骤 JRTPLib是RTP协议的开源版库,下面讲述在VS2008上面的编译步骤 JRTPLIB开源库包括两个jthread.l
内容一览:TVM 共有三种安装方法:从源码安装、使用 Docker 镜像安装和 NNPACK Contrib 安装。本文重点介绍如何通过源码安装 TVM。
1. POSIX 线程局限性 : 在 Android , Linux , UNIX , MAC 中可以直接使用 POSIX , Windows 不可以直接使用 ;
error LNK2001: 无法解析的外部符号 __GSHandlerCheck_EH4 这是因为编译boost用的是vs2019,这里调用的是vs2017,用2017重新编译boost1.82
Vcpkg 可帮助您在 Windows、 Linux 和 MacOS 上管理 C 和 C++ 库。 这个工具和生态链正在不断发展,我们一直期待您的贡献!
版权声明:本文为博主原创文章,转载请注明源地址。 https://blog.csdn.net/10km/article/details/80399355
《世嘉新人培训教材—游戏开发》作为经典的游戏开发教程,提供了相关样例代码供我们进行开发使用。但是该样例是基于VS进行编写构建的,而本人日常喜欢CLion进行C/C++开发,于是准备使用cmake重新组织该书籍的样例项目:2DGraphics1中的NimotsuKunBox和drawPixels。当然,这个过程不仅是移植,也是对cmake组织项目一个深入的实践。
在一个无所事事的周末下午,突然想起魔兽世界,官方的账号很久没有上了,里面的大小号现在连满级都不是。以前曾经搭过传奇和星际争霸战网的私服自娱自乐,也听说过魔兽世界有开源的服务端模拟,既然兴致来了就小小的研究一下。
之前曾使用 Visual Studio 2019 开发 CMake 项目 , 参考之前的博客 :
CGAL的编译以及在VS中的使用 在被CGAL长久的折磨了两三周 在学习过程中有好几次库都出现了问题 所以打算重新更换一下版本 CGAL可以说是学习这么久以来见过最离谱(ex)的环境配置,期间出了好几次问题,主要各个配置关联性太强了 稍有一步有问题 编译就很容易报错 所以想记录一下配置过程
查看cuda11支持的vs版本:https://docs.nvidia.com/cuda/cuda-installation-guide-microsoft-windows/index.html
cd /d D:\Cgal\cmake\boost_1_55_0_vc142 v142,需要修改msvc auto_link
之所以在愉快二字上加引号,相信编译过FFMPEG的同学会深有体会,根本不存在愉快二字,编译FFMPEG是痛苦,尤其是在Windows环境下面。打开搜索引擎随手搜索一把编译FFMPEG,就会有很多文章,我相信即使你老老实实按照文章的步骤来编译,也会心里骂娘的。
本文主要讲解 FFmpeg 相关知识,以及在 Windows 下编译 FFmpeg 源码以及使用。
下载后直接把headers和lib文件夹解压至项目文件夹内,它在本教程中不会用到,但是在使用LiteLoader的内置事件时有用
关于美化 Windows Terminal 及 Powershell,可以查看这篇优秀文章: Windows-Terminal 美化以及通过 OhMyPosh 美化 PowerShell
paho.mqtt.c是eclipse开发的C语言跨平台mqtt client 开源库,之前写过一篇博客《cmake:VS2015和GCC编译paho.mqtt C/C++ client》介绍如何编译它。 最近在使用的时候发现有个问题:paho.mqtt.c在MSVC编译的时候不能支持/MT编译。
前面一篇文件 https://blog.csdn.net/zhanggqianglovec/article/details/103344658 讲述了如果将多个影像拼接为一个大的影像,本文将讲述 一些上面工具在使用过程中的问题及其优化 1. 问题出现: 首先直接说一下工具上的缺陷: 1.1 该工具依赖的是 x86库,包括opencv 2.4.3 ,cholmod 1.6.0 都是32位的,32和64都会影响工具在处理影像时的性能,比如在处理索尼相机的照片时,分辨率是 6000*4000,20多张照片,在处理到一半时会爆出 申请内存失败的情况。(本地环境为 i5处理器四核,16G内存),处理索尼相机时每张照片都会申请 6000*4000 字节内存块,直接内存爆出内存申请失败。 1.2 该工具迁移到其他机子上会出现不兼容的问题,应为opencv 底层设计到 GPU,CPU等指令,所以在其他机子上 运行,稍微大一点的图片 都会爆出 内存申请失败的问题。 2. 问题定位: 接下来说一下问题的定位 刚开始一直以为是内存的问题,因为在处理小一点的图片时,是没有问题的。在处理所以相机时才会出现;但是当迁移到其他机子上的时候,当地环境是 200G的内存,任然会报出 内存问题,这个就不是内存问题了。然后网上查询,大部分的解决思路 都是 32与64的不兼容。知其然不知其所以然,最后通过仔细的查看爆出来的原因,才豁然大悟,opencv底层调用到了cpu、gpu的指令,然后opencv对底层32/64的支持并不是很好,也就是说 在64环境下调用32 的指令,会出现不兼容的问题,从而导致频繁的爆出内存问题,到此为止,已经定位的差不多了,爆出内存问题只是表象,底层是msvcp.dll/msvcr.dll的执行。 3. 解决之道: 既然问题已经定位到,那么解决之道又是什么,毫无疑问:从底层实现对64的支持,不依赖32位的相关东西。说白了就一句话:重新编译mosaic的所有依赖库,全部换为 64版本 应该就能解决问题。 4. OpenCV 2.4.9 64位的编译 4.1 OpenCV下载: Opencv库的编译相对来说简单,通过Cmake直接可编译,问题是Opencv的源码获取比较麻烦,通过github获取,在git下载过程中时常会出现git下载失败,原因是github连接到了外网,会有网路断开等情况,所以通过github上查找 opencv来下载 还是比较麻烦的,需要多试几次。好在opencv2.4.9 有可执行程序,直接安装 opencv2.4.9 即可安装 他的源码,这个比较好,一下子全部搞定。 4.2 OpenCV工程生成: 在选择 Visual Studio 编译版本的时候需要注意下,Opencv 有区分 X86,X64 和 IA及RAM的编译,这个需要根据自己的情况进行选择,64位环境下一定选择 X64,因为我用的时候 Visual Studio 2010,所以我选择的是 Visual Studio 2010 X64版本,然后点集 Configure,Generate,OpenProject 即可在 Visual Studio 2010中 打开 Opencv 的工程。 4.3 OpenCV 工程编译: OpenCV 工程打开后,找到 ALL_BUILD工程,选择Debug/Release版本,右键build,这个工程只会生成对应的lib库和dll库,并不会生成头文件。 INSTALL工程,该工程首先会执行ALL_BUILD工程,然后复制相关库(lib/dll)到install下的 lib目录和bin目录,复制指定头文件到 include目录,这个工程满足要求,右键 build ,工程执行完毕后会在install目录下生成include目录,bin目录和lib目录。 4.4 Opencv编译完成 5. Cholmod 3.1.0 64位的编译 5.1 Cholmod的获取 网上关于Cholmod的讲解很少,在网上找了很久,找到了SuiteSparse这个产品,SuiteSparse是一个产品套件,里面包含了很多图像相关的处理库,Cholmod只是其中的一部分,而且SuiteSparse目前代码都是针对Linux下的开发,没有针对Windows做 相关的操作,源码目录下不存在cmaketext.txt 文件,不能在windows下直接编译。难道要全部
版权声明:本文为博主原创文章,转载请注明源地址。 https://blog.csdn.net/10km/article/details/50581246
领取专属 10元无门槛券
手把手带您无忧上云