Should I use relative include paths for my project, or place the include-directory on the include path?

Question

In my project, I currently use relative paths to include my files, which admittedly doesn't change often. However, it yields pretty weird include patterns, because I usually nest my files in alot of folders.

For example, in my current project I have network/server/myfile.hpp. It needs to include common/log.hpp. Current I use #include "../../common/log.hpp" which is pretty verbose, but works.

If i instead add my main include directory on the path, I could simply include "common/log.hpp".

I know this question might be more about preference than anything else, but is there any objective pros and cons concerning cross platform applications and what about C++ conventions?

Answer 1

Relative includes paths with .. in it look a bit ugly and expect a certain filesystem structure, that is, "../../common/log.hpp" is two folders up. It makes sense to avoid unnecessary dependencies in general and on filesystem structure in particular, so that moving a header file from one directory to another does not force you to update all source files that include that header.

It is also elegant to have your includes correspond to namespaces and classes. If, for example, you have:

namespace foo { namespace bar { struct Baz; } }

It is convenient and intuitive to include it like:

#include "foo/bar/Baz.h"

Answer 2

By having #include <common/log.hpp> in your source file and having path to common/log.hpp in your project settings (compiler options) you are protecting your source code from changes in case common/log.hpp moves to some other place so I would recommend this approach. Note using angle brackets in this case - compiler should search for the header in directories which paths are specified by the /I compiler option.