#Include Absolute Path Syntax in C/C++

#include absolute path syntax in c/c++

Every implementation I'm aware of, and certainly MSVC 2005 and linux, allows you to specify the directory paths in which to find header files. You should include D:\temp\temp_lib on the list of directory paths, and then use

#include <temp.h>

For gcc, use -I path. For MSVC, see Where does Visual Studio look for C++ header files?

The reason that #1 isn't a syntax error is that, although it looks like a string literal, it isn't. The specification is

#include "q-char-sequence"

Where q-char is

any member of the source character set except the new-line character
and "

In particular, \ has no special meaning. The interpretation of the q-char-sequence is implementation-defined.

C++ include with full path

You simply need to ensure that your build process sets an option to specify the starting point of the search.

For example, if your header is in:

/work/username/src/project/app/submodule/thing.h

then you need to include (assuming a POSIX-compliant compiler; AFAICR, even MSVC uses /I as the analogue of -I):

-I/work/username/src

as one of the compiler options. You can use that path from anywhere in your project since it is absolute. You just need a defined way for your build system to know what the setting should be, so that when it is moved to /home/someone/src/, you have only one setting to change.

How do I have to describe an absolute path to a file in C++?

In C++17 you can use the filesystem library and hard code the path, if this is what you really want to do.

#include <filesystem>
#include <fstream>

namespace fs=std::filesystem;

int main() {

  fs::path p = "your-absolute-path-goes-here"; // 
  if(fs::exists(p)) {
    std::ofstream file(p);
    file << "Hello world!" << "\n";
  }
  return 0;  
}

Getting absolute path of a file

Use realpath().

The realpath() function shall derive,
from the pathname pointed to by
file_name, an absolute pathname that
names the same file, whose resolution
does not involve '.', '..', or
symbolic links. The generated pathname
shall be stored as a null-terminated
string, up to a maximum of {PATH_MAX}
bytes, in the buffer pointed to by
resolved_name.

If resolved_name is a null pointer,
the behavior of realpath() is
implementation-defined.

---

The following example generates an
absolute pathname for the file
identified by the symlinkpath
argument. The generated pathname is
stored in the actualpath array.

#include <stdlib.h>
...
char *symlinkpath = "/tmp/symlink/file";
char actualpath [PATH_MAX+1];
char *ptr;

ptr = realpath(symlinkpath, actualpath);

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.

How can I avoid explicitly declaring directory paths in C or C++ #include directives?

Really it all depends on your include path, different compilers might call it different things but in gcc

-Idir  Append directory dir to the list of directories searched for include files.

So in your example you would specify ../world etc... in the list of directories in -I

Include Path Directory

You are using quoted form of include directive, it searches for include files in this order:

1. In the same directory as the file that contains the #include statement.
2. In the directories of the currently opened include files, in the reverse order in which they were opened. The search begins in the directory of the parent include file and continues upward through the directories of any grandparent include files.
3. Along the path that's specified by each /I compiler option.
4. Along the paths that are specified by the INCLUDE environment variable.

Further reading:
https://msdn.microsoft.com/en-us/library/36k2cdd4.aspx

#include directive: relative to where?

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

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.

---

Related Topics