Relative Include Files

What are the benefits of a relative path such as ../include/header.h for a header?

I prefer the path syntax as it makes it very clear what namespace or module the header file belongs to.

#include "Physics/Solver.h"

Is very self-describing without requiring every module to prefix their name to header files.

I almost never use the ".." syntax though, instead I have my project includes specify the correct base locations.

Using (relative) paths to shortcut in include statements in C++

It really depends on how you include the header files.

If you include with double-quotes, like e.g.

#include "some_header_file.h"

Then the relative path is from the current files location.

If you include using angle-brackets, like e.g.

#include <some_header_file.h>

Then the relative path is based on the system include paths.

You can always add a path to the system include path. How to do it depend on your environment and compiler. If you're using Visual Studio you go into the project properties dialog, and in the "C/C++" / "General" tab there is a field called "Additional Include Directories" where you can add directories. (This is for VS 2015, might be a little different on other versions.)

---

Regarding double quotes inclusion. Lets say your project hierarchy looks like this (on disk!):

Project
|-- Include
|-- Source
|   `-- MoreSource
`-- Other

In Project/Source you have your source files, and if one of them want to include a header file from Project/Include, then it will look something like

#include "../Include/header.h"

Now if you have a source file in Project/Source/MoreSource that want to include the same header file it will be

#include "../../Include/header.h"

It could be useful to add the Project/Include directory to the system header search path. You can still use double-quotes to include the files, since if they are not found then the preprocessor will search the system paths as well, but you don't need the "full" relative path. If you add Project/Include to the system header path, you could write just

#include "header.h"

Or

#include <header.h>

Be careful though, if you have a header file with the same name as an actual system header file you might have some trouble.

c/c++ relative include paths vs Makefile include flags

It depends. For include files inside your project, giving the relative path can be useful, as the sub-directory is another structure-element and you do not have to care about equal file-names (mostly for C++, as C does not support custom-namespaces).

For external paths (e.g. other projects), you should definitively use the second method. Possibly just to the root of that structure. Similar to asm/byteorder.h.

In any way, if using explicit paths (in the source files), you should make sure they are well-documented and any change is tracked to the source files. (There are often common sub-directories, like config, etc. which will not change).

One strong recommendation: always use the project root as working directory. All explicit relative paths are from this root. That way you can avoid the problemativ parent (..) path.

Ultimative rule is not to use explicit paths which cross the project-root.

However, there is no other general rule. The actual layout is often subject to personal preferences. If the directory structure is well-thought, I'd prefer explicit paths.

Is it possible to specify a #include file path relative to the user's current directory when compiling?

If you consistently use <> includes, then the -I options in the makefile should be enough. The directory layout shows only one makefile, in the parent directory. That could use

-Idir_a -Idir_b

in the compiler options, and the .c files could just do

#include <a.h>
#include <b.h>

One of the problems with quoted includes is that their behavior with other compilers may differ, as noted in What is the difference between #include <filename> and #include “filename”? (the standard was not explicit enough). Using a gcc extension probably does not improve that situation.

making relative path for include files

I always included a config.php in the first line of each php:

require_once($_SERVER['DOCUMENT_ROOT']."/".(explode ('/', $_SERVER['PHP_SELF'])[1])."/config.php");

This code should always find the root directory, and then include the config.php file.
Note that you can put this file anywhere you want - it will always find it's location on its own. If you move the file to another directory subsequently, you don't have to change anything.

This config file then defines the paths to all subdirectories and other important files, relative to the root directory:

$paths = array(
    "root" => "",
        "controller"    => "controller",              
        "stylesheets"   => "css",
        "images"        => array(
             "icons"    => "img/icons",
             "controls" => "img/controls"
             ),
        "javascript"    => array(...),
        ...
);

This array means, that the root folder (your public_html) contains the directories "controller", "stylesheets", images" and so on. Images are either placed within "img/icons" or "img/controls".

All other files are included so:

require_once($paths['helper']['html']."/form.php");

This can be very useful, because it allows you to restructure your complete directory layout, and you only need to update your config.php.

And, last but not least, the config also contains a function like this:

$projectName = "YourProjectFolderName";
function fInc($filePath){
    global $projectName;
    return '//'.$_SERVER['HTTP_HOST'].'/'.$projectName.'/'.$filePath;
}

It can be used to convert paths which will be inserted into the HTML document.

Edit:
Note, that defining an array with all paths is just a suggestion. It helped me in my projects, as I often restructure my project layout. If you don't do that in your project, you can just define a

$rootDir = $_SERVER['DOCUMENT_ROOT']."/".(explode ('/', $_SERVER['PHP_SELF'])[1]);

and then include files with

require_once($rootDir . "/home/index.php");

This way, you won't need the config.php anymore.

#include directive: relative to where?

Implementation defined. See what is the difference between #include <filename> and #include “filename”.

What is the path relativeness of the files to include in VS Code's search?

It depends on whether it resembles an absolute path or not. If it's just a file/folder name, then it resolves to being relative to the root folder of your workspace as displayed on the Explorer panel. Otherwise, it gets treated as an absolute path.

For example:

Here, I added/opened the folder TEMP as the root folder.

If I put just src (just the folder name, without the leading / ), then it will recursively match all name files/folders under /path/to/TEMP/, no matter the depth (as shown in the image above):

• /path/to/TEMP/src
• /path/to/TEMP/aaa/src
• /path/to/TEMP/xxx/yyy/src

This is explained in the Advanced search options docs:

If you enter example, that will match every folder and file named example in the workspace

My emphasis on the "in the workspace" part. It's also subtlety mentioned there that this is similar to explicitly entering **/src to mean "match any number of path segments, including none" in the workspace.

In the search view, the ** prefix is assumed

If I put ./src (looks like a path, with a leading .), this would still be relative to the workspace and it is the same as /path/to/TEMP/src. This is again mentioned in the docs:

If you enter ./example, that will match the folder example/ at the top level of your workspace

If I put src/ (with a trailing /), the trailing / is ignored and it goes back to being relative to the root folder. This is similar to just using src.

Now, if I put /src (looks like a path, with a leading /), it is a bit different. It now gets treated as the absolute path /src, which is not relative anymore to the root folder. Compared to the outputs above, this yields no matches on my env because there's really nothing there.

To make this less confusing, I usually just provide the file/folder name itself, to make it always relative to the root folder. I don't put any / or . or ...

To make it simpler to search for stuff, if you know the specific parent folder of the src folder you want to find in, you can just specify that:

You can even specify multiple parent folders as comma-separated names, and you can also use ** to recursively "match any number of path segments, including none":

Usually though, the easier way is to simply use the files to exclude setting instead, to exclude files/folders you don't want to be included in the search. You mentioned "I also get results in some build folders like /Project/android/src". So the best way here is to exclude that folder from search.

As mentioned in the comment, if you want to regularly/always exclude certain files/folders from search, there are the files.exclude and search.exclude settings:

VS Code excludes some folders by default to reduce the number of search results that you are not interested in (for example: node_modules). Open settings to change these rules under the files.exclude and search.exclude section.

How to define relative paths in Visual Studio Project?

If I get you right, you need ..\..\src

How to set includes to be relative to the relativity of the source file from the root path?

There is no magic compiler option to do what you want.

Solution 1: Change the #include directives to be relative to the include directory.

Solution 2: Don't use separate directories and move the headers into src directory.

---

Related Topics