Call Boost libraries in C++ - visual-c++

I have built the Boost library from these instructions:
http://stackoverflow.com/questions/3529163/install-boost-library-in-visual-c-2008
Directory of the unzipped Boost folder is C:\Users\David\Desktop\boost_1_44_0. I have called Visual C++ 2010. How to use Boost in a program?
I mean I want the following.
#include<boost>

Tweak your project properties to add C:\Users\David\Desktop\boost_1_44_0 to the include path and maybe the link path if you plan to use the part of Boost that is not include-only (libboost_filesystem for instance).

You have to include the header path and library path in your project.
Also #include <boost> won't do anything. You have to include each individual feature of boost that you need. For instance if you need to link to the filesystem.lib file in to boost directory, and use #include "boost/filesystem.hpp".
Take a look at this answer from step 6: Another Answer

Related

Rcpp with structured library in /src

I'm trying to write a wrapper for a C++ function I've written, making use of the Point Clouds Library (PCL). This is my first try interfacing R and C++, so I apologise if any solution is too trivial. My goal is to make a few functions available for myself and my colleagues directly in R, on mac and windows. My example function cloudSize is included at the bottom of the text. I will try to be as clear as possible.
I've installed PCL with the vcpkg package manager for winx64 at C:\src\vcpkg\vcpkg.
This is added to my Environmental Variable Path for my user.
I created an empty R-package with Rcpp.package.skeleton():
C:/User/csvi0001/Desktop/GitHub/RPCLpackage/PCLR
PCL is a massive library, but thankfully modular,and so I only #include the headers that are needed to compile the executable: pcl/io/pcd_io.h, pcl/point_types.h, pcl/registration/icp.h.
Now, since I'd like this to work on more than one OS - and therefore compile on install (?) - I should use a dynamic library? I'll presume that the person installing my package already has a compiled copy of pcl. However, I do not know how to find a flag showing that pcl is installed - how do I find these for inclusion in Makevars(?). CMake must find them when testing the C++ function in VSCode after adding an include path. In lieu of this:
I copy the pcl folder installed by vcpkg to ./src . When I tried copying all the .h files, they seemed to lose track of one another as they refer to eachother through which module they are placed in, e.g. <pcl/memory.h> cannot be found if memory.h is placed directly in ./src. However, flattening the structure of the modules means that every single dependency and #include must be manually changed, in some cases there are also files with the same name in different folders. e.g. pcl/kdtree.h and pcl/search/kdtree.h. After this, it must be done again when replacing < > with " " for each header.
Is there any way of telling Rcpp that the library included in /src is structured?
I'm working on Win 10 winx64.
Since I'm making use of the depends RcppEigen and BH; and I must have C++14 or higher (choice: C++17) I add to my DESCRIPTION file:
LinkingTo: Rcpp, RcppEigen, BH
SystemRequirements: C++17
My actual C++ function:
//PCL requires at least C++14
//[[Rcpp::plugins(cpp17)]]
//[[Rcpp::depends(RcppEigen)]]
//[[Rcpp::depends(BH)]]
#include <Rcpp.h>
#include <iostream>
#include "pcl/io/pcd_io.h"
#include "pcl/point_types.h"
#include "pcl/registration/icp.h"
//[[Rcpp::export]]
int cloudSize(Rcpp::DataFrame x)
{
pcl::PointCloud<pcl::PointXYZ> sourceCloud;
for(int i=0;i<x.nrows();i++)
{
sourceCloud.push_back(pcl::PointXYZ(x[0][i],x[1][i],x[2][i])); //This way of referring to elements in a Rcpp::DataFrame may be erroneous.
}
int cloudSize = sourceCloud->size();
return (cloudSize);
}
That is a non-trivial question. In the simplest case, use a 'hook' offered by configure and configure.win to pre-build a (static) library you ship in your sources and then link your package to that.
That said, the Writing R Extensions manual and/or the CRAN Repository Policy (both of which are the references here) expressed more of a preference for an external library -- which may not be an option here if PCL is too exotic.
As the topic comes up with Rcpp, I wrote a short paper about it (at arXiv here) which is also included as a vignette in the package. It requires a few pages to cover the common cases but even then it cannot cover all.
Your main source of reference may be CRAN. The are lots of packages in this space. A few of mine use external libraries, I contributed to package nloptr which uses a hybrid approach ("use system library if found, else build") and some like httpuv always build (a small-ish library).

Boost thread library version mismatch

I've created a managed C++ log parser application using C++ vectors and Winforms. I want to add multithreading and Boost seemed like a better option than Winforms BackgroundWorker because I want to be able to execute my existing C++ function with each thread. I installed Boost multiple times following multiple different tutorials (lastly this one: https://levelup.gitconnected.com/the-definite-guide-on-compiling-and-linking-boost-c-libraries-for-visual-studio-projects-c79464d7282d) and I still have the same issue when I try to #include <boost/thread.hpp>
Error LNK1104 cannot open file 'libboost_thread-vc143-mt-x64-1_78.lib'
I don't know why it's looking for this library when I have Boost 1_79 installed not 1_78. My .lib file also has "mt-gd-x64" not just "mt-x64". I've already specified the correct file path to the library in Project->Properties->Linker->General->Additional Library Directories. I've also tried installing Boost via Visual Studio 2022 NuGet Package Manager. The lib file in that folder is also slightly off. "vc120" instead of "vc143". I've even tried changing the .lib file name to match the file name in the linker error exactly but when I do that I get more errors like LNK1104 cannot open file 'libboost_chrono-vc143-mt-x64-1_78.lib'
Do I just need to delete all my Boost files and download version 1_78 and try again? Why is Visual Studio looking for the wrong file name when it compiles? Is my #include statement wrong?
I ended up solving this problem by downloading boost 1_78, building it, and specifying that folder instead or the 1_79 folder. If anyone might know why the program was looking for 1_78 instead of 1_79 feel free to respond Also big thanks to George Gkasdrogkas who wrote the tutorial that worked best for me on how to install Boost. Tutorial is linked in the question :)

Can I build static library that main component is header file(.h) with NDK?

I want to convert my cpp code for static library into Android library.
For this, I'm attempting to use NDK.
But I read NDK documentation and it said that only source code is able to be input for building, "Android.mk".
My Questtion is "Is there any way to build static library for Android system with my cpp library?"
Top module of my cpp library is header file and it can be built on Windows system as ".lib".
Thank you!
Your cpp library should be built with NDK toolchain as "libyourname.a" to begin with. You don't need Android.mk for that, even though in many cases deriving a standards-compliant Android.mk is trivial, and makes the developer's life happier in the long run (See, e.g., github).
The next step should be to prepare a JNI wrapper dynamic library (shared object, .so), which can be loaded from your Java app. That "libyourname_jni.so" will probably have its own, separate Android.mk file. Well, Java is not a must: you can use NativeActivity, or maybe some alternative frameworks.
I suggest the following reading to understand the whole process: http://thesoftwarerogue.blogspot.co.il/2010/05/porting-of-libcurl-to-android-os-using.html

VC++ 2010 wants to link boost libararies i didn't even specify

I'm trying to build my application with MSVC 2010 instead of GCC. With GCC everything works fine. My app uses boost_system and boost_thread libraries.
I built boost with VC2010 in "system" layout, that means the libraries are named just libboost_system.lib (and not libboost_system_compiler_threading_version_wtf_snafu.lib)
The libs reside in C:\Boost\lib,
the Makefile specifies
LFLAGS = /NOLOGO /INCREMENTAL:NO /SUBSYSTEM:CONSOLE
LIBS = /LIBPATH:C:/Boost/lib libboost_system.lib libboost_thread.lib Ws2_32.lib
when invoking nmake it compiles, but when trying to link it quits with
LINK : fatal error LNK1104: cannot open file 'libboost_date_time-vc100-mt-1_43.lib
I mean seriously, WTF? I told it to link libboost_systen.lib and libboost_thread.lib how come it tries to link libboost_data_time and why does it assume I built the libs in "tagged" layout??
How can I stop MSVC trying to be smart and guess what I might have wanted to link?
Thanks,
Philipp
This is a feature of the Boost libs with compatible compilers for automatic linking.
(Those convoluted library names cover the myriad of threading and linking options that are available on the platform; there are good reasons to use that convention on Windows...)
More information here:
http://www.boost.org/doc/libs/1_33_1/more/getting_started.html#auto-link
I can't find a page for a more recent version, but I believe the BOOST_ALL_NO_LIB and related options are all still valid in 1.43.
Assuming you are auto-linking (i.e. you've defined BOOST_ALL_DYN_LINK or library specific equivalents).
For layout 'system' you have to define the preprocessor macro:
BOOST_AUTO_LINK_NOMANGLE
to link to the correct library names.
For layout 'tagged' you have to define the preprocessor macro:
BOOST_AUTO_LINK_TAGGED
to link to the correct library names.
I don't know if you could do this override for some libraries and keep the default for others. That would be a very cumbersome setup I'd imagine.

How can I link against the debug/release libraries automatically in VC++ 6.0?

I am trying to maintain a program written 5 years ago in VC++ 6.0. It uses our 'common' libraries. The trouble I have is that it either links against the debug version of these libraries or the Release version, depending on whether I have the [Directories] for [library files] set to "common/debug" or "common/release" in [Tools]->[Options].
How do I get it to link to [common\debug\common.lib] when building the debug version and [common\release\common.lib] when building the release version? If I have both paths in the library directories, it seems to link to the first one it finds.
Instead of specifying the paths in the include folders and all the best way i use to include the libraries depending on the configuration is by using #pragma
try this once, it is very useful
#ifdef _DEBUG
#pragma comment(lib, "..\\DllTest\\Debug\\DllTest.lib")
#else
#pragma comment(lib, "..\\DllTest\\Release\\DllTest.lib")
#endif
In [Project Properties]->[Linker]->[Input]->[Additional Dependencies] you can use the $(ConfigurationName) placeholder, like this:
c:\common\$(ConfigurationName)\common.lib
In the Debug configuration this will change to:
c:\common\Debug\common.lib
and in Release it will change to:
c:\common\Release\common.lib
If I have both paths in the library directories, it seems to link to the first one it finds.
Just add the debug folder for the debug settings and the release folder for release settings.
Almost all compiler, linking etc. settings are per configuration (the project properties will show settings as blank in "all configurations" (if I recall the right text) if debug and release are different.
You could specify the full path of the library to link to in the Additional Dependancies field, this can have different values for debug and release builds.
The solution I have found is a little like Richard's & "1800 Information"'s...
I removed the Common library path from Tools->Options. The paths in here are global to all configurations of all projects running in MSVS VC++ 6.0.
I then added a full path to the appropriate library in Project->Settings for each configuration. Hense the debug configuration has D:\VSS\Common\Debug\Common.lib and the release configuration has D:\VSS\Common\Release\Common.lib. This seems to work and for the first time I have no build warnings!
Thanks to all the suggestions for pointing me in what seems to be the right direction.
--- Alistair.

Resources