1

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.

Abhishek Ranjan
  • 498
  • 3
  • 17
Oscar
  • 279
  • 1
  • 10
  • 1
    I would remove all directory prefixes from the #include directives, and add the directories to the compiler C/C++ configuration. – schwart Jun 18 '20 at 20:09
  • So the responsibility would then fall upon the person who clones the repo to add the \include directory to his compiler configuration when running my program? Is that typical? – Oscar Jun 18 '20 at 20:14
  • 1
    To elaborate a bit further on @schwart's comment, the C++ configuration is something you would typically put under source control. For Windows, this would be your solution and project files (visual studio or other IDE), for Linux possibly a Makefile. Going one step further, a lot of open source repos use CMake so that users can generate VS project files (for example) without being tied to a specific version. That said, if you are developing a library others will use, then yes, it is normal to have to specify include/linker settings in order to link the library. Hope that makes sense! – castro Jun 18 '20 at 21:19
  • Hey, is "source control" a standard folder I should have on my github repo or something deeper than that? Should those files then automatically look in the additional include directories I have specified in visual studios? I found that this wasn't the case when I tried cloning my repo on another machine. It's not really a library, more of a stand-alone program, does that still hold? – Oscar Jun 18 '20 at 21:42

2 Answers2

1

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.

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
0

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.

Zeus
  • 3,703
  • 3
  • 7
  • 20