While setting up the Eigen library, I tried:
#include <eigen/Eigen/Dense>
Which results in the error:
eigen/Eigen/Dense: No such file or directory
However,
#include "eigen/Eigen/Dense"
succeeds.
Why is this? Based on previous questions asked, I suspect this is because #include <> searches in the system directory and #include "" searches locally. If this is true, how would one put the Eigen folder in the system directory?
You will need to follow the instructions that are specific for your operating system. You did not describe your operating system and compiler, and this is something for which no standard instructions apply for every operating system used in the world today. It varies by operating system and compiler.
Alternatively, all C++ compilers have a configuration setting that adds an additional directory to the list the compiler looks when searching for #include <path> header files. gcc, and many other Linux compilers use the -I option. This can be specified manually, or in a Makefile.
MS-Windows compilers have a specific settings too. This Stackoverflow question provides instructions for several versions of the Visual Studio IDE.
Related
I've been struggling back and forth with this for a while now looking stuff up and asking questions and I'm still at a crossroads. What I've done so far and where I'm currently at based on what I've been told is this: I've added 2 directories to my repo: src for my .cpp files and include for my .hpp files. In my include directory I have all the .hpp files directly in the folder where as in my src directory I have several sub-directories grouping my .cpp files according to the purpose they serve e.g. \src\ValuationFunctions\MonteCarloFunctions\FunctionHelpers.
I've changed the name of all the #include "header.h" to #include "..\include\header.h". This works for my main file which is directly in the src folder but I found now that it doesn't work for my .cpp files that are in sub-directories like in my example above, it would seem I would have to navigate back to the root folder doing something like #include "../../..\include\header.h" which obviously can't be the way to go.
How do I make this work, am I even on the right track here? I have uploaded my repo to github (https://github.com/OscarUngsgard/Cpp-Monte-Carlo-Value-at-Risk-Engine) and the goal is for someone to be able to go there, see how the program is structured, clone the repo and just run it (I imagine this is what the goal always is? Or does some responsibility usually fall on the cloner of the repo to make it work?).
I'm using Windows and Visual Studios, help greatly appreciated.
How properly specify the #include paths in c++ to make your program portable
Please read the C++11 standard n3337 and see this C++ reference website. An included header might not even be any file on your computer (in principle it could be some database).
If you use some recent GCC as your C++ compiler, it does have precompiled headers and link-time optimization facilities. Read also the documentation of its preprocessor. I recommend to enable all warnings and debug info, so use g++ -Wall -Wextra -g.
If you use Microsoft VisualStudio as your compiler, it has a documentation and provides a cl command, with various optimization facilities. Be sure to enable warnings.
You could consider using some C++ static analyzer, such as Clang's or Frama-C++. This draft report could be relevant and should interest you (at least for references).
The source code editor (either VisualStudioCode or GNU emacs or vim or many others) and the debugger (e.g. GDB) and the version control system (e.g. git) that you are using also have documentation. Please take time to read them, and read How to debug small programs.
Remember that C++ code can be generated, by tools such as ANTLR or SWIG.
A suggestion is to approach your issue in the dual way: ensure that proper include paths are passed to compilation commands (from your build automation tool such as GNU make or ninja or meson). This is what GNU autoconf does.
You could consider using autoconf in your software project.
I've changed the name of all the #include "header.h" to #include "..\include\header.h".
I believe it was a mistake, and you certainly want to use slashes, e.g. #include "../include/header.h" if you care about porting your code later to other operating systems (e.g. Linux, Android, MacOSX, or some other Unixes). On most operating systems, the separator for directories is a / and most C++ compilers accept it.
Studying the source code of either Qt or POCO could be inspirational, and one or both of these open source libraries could be useful to you. They are cross-platform. The source code of GCC and Clang could also be interesting to look into. Both are open source C++ compilers, written in C++ mostly (with some metaprogramming approaches, that is some generated C++ code).
See also this and that.
In program development, it is often necessary to use toolkits developed by others. Generally speaking, in Visual Studio, source files are rarely used, and most of them use header files and link libraries that declare classes. If you want to use these classes, you need to include the name of the header file in the file, such as #include "cv.h". But this is not enough, because this file is generally not in the current directory, the solution is as follows:
Open "Project-Properties-Configuration Properties-C/C++-General-Additional Include Directory" in turn and add all the paths.
For all kinds of IDEs, we can do similar operations to include directories. So for those who clone the project, it is quite normal to modify the directory contained in the project.
Dev-C++ cannot find the I/O stream header files. I tried it with both #include <iostream> and #include <iostream.h> but I get the following errors.
[Error] iostream.h: No such file or directory
[Error] iostream: No such file or directory
What can I check in the Dev-C++ settings to make sure it's properly configured to build programs that use the C++ Standard Library?
#include <iostream>
You've got a double 's' in your code as far as I can see and that may be causing a problem. If including "iostream" header file won't work as well it means that your Dev-C++ (sic!) is probably not linked with MinGW properly.
As the others said, consider using f.e. Code::Blocks instead Dev-C++.
If you didn't download the Dev C++ that includes MinGW then you don't have the standard libraries. If you do have the standard libraries you will need to make sure to set it up by pointing it to the location of the source on your system.
If you still need the standard libraries, you can go to "Downloads" section of this page and go to the first link which includes MinGW.
But your best bet is to send Dev C++ off to die in a fire. The incredibly powerful Visual Studio 2015 is out and the Community version is free: https://www.visualstudio.com/downloads/download-visual-studio-vs There's really no excuse for using anything else on Windows.
Is there some sort of documentation for what kind of headers you can include in c++ files when writing programs for Raspberry Pi or linux in general?
For instance I found this great guide on how to access the SPI bus from the Pi using c++ (http://hertaville.com/2013/07/24/interfacing-an-spi-adc-mcp3008-chip-to-the-raspberry-pi-using-c/)
I was able to take the code and apply it to my situation and was succesfully able to talk to an nRF24L01+ RF module and I am able to command the chip etc.
But as I started trying to investigate what the code does (because I like to know how code that I get from the internet works) I get lost very quickly. For instance how did the author of that code know to include the header files he did:
#include <unistd.h>
#include <stdint.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/spi/spidev.h>
#include <stdio.h>
#include <errno.h>
#include <stdlib.h>
#include <string>
#include <iostream>
I know what the ones such as "iostream" do but I thought I would approach it by Googling those header file names such as ("unistd.h") but no luck. I found lots of info but none pertaining to the Pi, and the little bit I did only started referencing other header files and code. Is this too much to try and learn, like would I effectively be trying to learn the linux kernel? Are there any good books for this type of stuff?
And back to my original question is there any kind of online (or offline for that matter) documentation for what header files you can include in your c++ projects on the Pi and what functionality they all add?
I found this (http://www.cplusplus.com/reference/) which has the standard files, but how do you know about all the non-standard header files and corresponding functionality?
All thoughts and help are appreciated, thanks!
Wesley
Edit 1
Here is the image showing the output of the "ls /usr/include" command:
TL/DR:
I've tried to have a general introduction to this topic below. If you are a more hands-on type and want to skip the wall of text, jump to the end. There are some tutorial links down there. Jump in -- getting stuck leads to the kind of questions Stack Overflow is best at.
Headers vs Libraries in C/C++
There is an important distinction to be made between header files and libraries in C++. Header files are the visible thing in your code, since they are what you actually mention in an #include statement. In most cases, though, the headers you are including correspond to libraries installed on the system.
As a practical matter this is important for two reasons:
You don't generally install "headers" on your system, you install libraries that happen to come with headers. There are a small number of header-only libraries that are exceptions to this rule, but usually you have a binary library somewhere that the header is facilitating access to.
The #include statement is only half of the story. There is usually a corresponding compiler option where you need to specify that you want to link against a particular library. In an IDE, this will be buried in the project options somewhere. For a command line compiler, this will be a switch that you pass to the compiler on the command line or (more commonly) in a Make file or similar.
That second point is actually true of your standard libraries like iostream or stdio.h, but these are backed by the standard C or C++ library that is linked in by default.
Linux in general
Most linux distributions will come with a package manager of some kind. There are a number available (Ubuntu uses Apt, Redhat uses yum, Arch has pacman, Gentoo has portage, etc.) The actual manager used is one of the defining properties of the distribution. Documentation will be easy to find on your Distro's web page. This is a very important tool to understand.
With the exception of the various C/C++ and Posix standard headers, the headers you have available for use are a function of the libraries you have installed on your system. This is important to understand because the list of available headers consists of all the available libraries on the internet, not just the few that your system happens to have installed at the moment.
Each library will generally be wrapped up as a package for your linux distro. When you locate a library that you want, you install the corresponding package. This will give you the required header and library files.
It actually isn't often useful to go looking for the libraries and headers on your hard drive, but if you are curious, header files conventionally end up somewhere in one of the following directories (or a subdirectory inside these)
/usr/local/include
/usr/include
Libraries will mostly be found in
/lib
/usr/lib
/usr/local/lib
These will have cryptic names that include their version number, and a more general (still cryptic) name that symlinks to the one with the specific version number.
Some distributions have separate "development" versions of libraries that include the headers, and only install the runtime files by default (ie the files your users need to run your program). If your distro does this, you'll need the development package to write software with that library.
When you have decided on what functionality you require, you generally go looking for a library that will help you accomplish that task. You can ask around on forums, or just google for them.
Device drivers in the Kernel
Most libraries will interface with a device through a device driver. In linux, device drivers are compiled into the kernel, or present as modules that are loaded into the kernel. Your Pi distribution will hopefully have come with all the required drivers for the hardware present. If not, you'll need to obtain a kernel module or recompile your kernel to include the required driver. The modules and appropriate scripts to load/unload them are generally available as packages for your distro, just as libraries are.
It is possible to write software to talk to a driver directly. This is a VERY broad topic. Your best bet is to pick a device (ie I2C, SPI, etc) and google for a tutorial for interfacing with that device on the Pi specifically.
This tutorial addresses the basics of writing a loadable module. It would be a good place to start if you want to write your own SPI driver.
This is a good place to go for a general kernel overview. It will help you understand what is available, how to get a copy of the kernel source, etc. This is also good knowledge to have if you want to write a driver. It is also a place to learn how to get your code submitted to the kernel, if you develop something new.
Finally, writing your own device drivers is possible, and isn't something to be scared of. The details of this topic that could fill a book, though, so it is something to google when you are ready to try it.
Linux on the Raspberry Pi
The first thing to understand about the Pi is that it is in most ways no different from a PC running linux. Any general information you find about systems programming for linux on a PC will apply equally to the Pi. The only caveats are that the processor architecture is different (ARM, vs Intel/AMD), and the Pi has a few hardware items (like I2C, SPI and GPIO) that are not common, or at least not commonly interfaced with, on the PC.
There is actually more than one linux distribution available on the Pi. These are usually derived from common PC distributions -- Ubuntu derived distros are most common. You'll want to locate the website for whichever distro you have.
If you try to install things outside of your package manager, you'll need to be careful to get libraries compiled for the ARM processor (or source libraries that you compile yourself). There are a few exceptions, but the vast majority of open source libraries should be usable on ARM.
This looks like a promising library that might be a good starting point.
This looks like a good GPIO (General Purpose Input/Output -- ie, pins you can toggle) tutorial.
This leads to some some SPI sample code.
I'm developing a software on an Arch Linux platform with NCurses. It has an #include <ncurses.h> in a global header.
My collaborator works in Windows and emulates a bash shell with Cygwin. However, cygwin installs ncurses libraries such that you have to use #include <ncurses/ncurses.h>. It's trivial to change, but our Git history could consist of that line changing back and forth multiple times if one of us forgot which seems silly.
Is there some kind of preprocessor check I could do to use the appropriate path?
As #BoBTFish said, you should specify the include path in the Makefile (different for each platform). If not, you can use the macro __CYGWIN__ (or __CYGWIN32__, not sure which one will work) to detect if you're using cygwin, like
#ifdef __CYGWIN__
#include <ncurses/ncurses.h>
#else
#include <ncurses.h>
#endif
See http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/predefined-macros-platform.html for more details.
In C++, does one need to copy any needed header files into the directory of the main C++ file?
Ex. I have OpenCV installed globally, and the Python bindings are working well. However, if I write:
#include "opencv2/highgui/highgui.hpp"
I receive a "not found" error. Do I need to copy these from their global install location to the project dir? I'm certain there must be a well-established set of practices for this, so I don't want to poke around in the dark on my own.
It depends on which operating system and build tool chain you are using, but as an example using linux, gcc and cmake, this article shows how to build with opencv.
http://docs.opencv.org/trunk/doc/tutorials/introduction/linux_gcc_cmake/linux_gcc_cmake.html
As you can see with the find_package directive, cmake is searching for the opencv include files.
Obviously, you can specify include path directly with g++ -I, but having cmake find it for you has the advantage that it will have a better chance of being found if you compile on a different system. It will also give you an error if it can't find the files.
Lastly, you should ensure that you have the "dev" files, as opposed to just the library. The dev files will have headers to include. While, the library will only have shared objects (*.so) and archives (*.a) that can be used for static or runtime linking.
If it is installed globally, you need to inform the compiler to look globally, i.e.,
#include <opencv2/highgui/highgui.hpp>