Related
What is the difference between using angle brackets and quotes in an include directive?
#include <filename>
#include "filename"
What differs is the locations in which the preprocessor searches for the file to be included.
#include <filename> The preprocessor searches in an implementation-defined manner, normally in directories pre-designated by the compiler/IDE. This method is normally used to include header files for the C standard library and other header files associated with the target platform.
#include "filename" The preprocessor also searches in an implementation-defined manner, but one that is normally used to include programmer-defined header files and typically includes same directory as the file containing the directive (unless an absolute path is given).
For GCC, a more complete description is available in the GCC documentation on search paths.
The only way to know is to read your implementation's documentation.
In the C standard, section 6.10.2, paragraphs 2 to 4 state:
A preprocessing directive of the form
#include <h-char-sequence> new-line
searches a sequence of implementation-defined places for a header identified uniquely by the specified sequence between the < and > delimiters, and causes the replacement of that directive by the entire contents of the header. How the places are specified or the header identified is implementation-defined.
A preprocessing directive of the form
#include "q-char-sequence" new-line
causes the replacement of that directive by the entire contents of the source file identified by the specified sequence between the " delimiters. The named source file is searched for in an implementation-defined manner. If this search is not supported, or if the search fails, the directive is reprocessed as if it read
#include <h-char-sequence> new-line
with the identical contained sequence (including > characters, if any) from the original
directive.
A preprocessing directive of the form
#include pp-tokens new-line
(that does not match one of the two previous forms) is permitted. The preprocessing tokens after include in the directive are processed just as in normal text. (Each identifier currently defined as a macro name is replaced by its replacement list of preprocessing tokens.) The directive resulting after all replacements shall match one of the two previous forms. The method by which a sequence of preprocessing tokens between a < and a > preprocessing token pair or a pair of " characters is combined into a single header name preprocessing token is implementation-defined.
Definitions:
h-char: any member of the source character set except the new-line character and >
q-char: any member of the source character set except the new-line character and "
The sequence of characters between < and > uniquely refer to a header, which isn't necessarily a file. Implementations are pretty much free to use the character sequence as they wish. (Mostly, however, just treat it as a file name and do a search in the include path, as the other posts state.)
If the #include "file" form is used, the implementation first looks for a file of the given name, if supported. If not (supported), or if the search fails, the implementation behaves as though the other (#include <file>) form was used.
Also, a third form exists and is used when the #include directive doesn't match either of the forms above. In this form, some basic preprocessing (such as macro expansion) is done on the "operands" of the #include directive, and the result is expected to match one of the two other forms.
Some good answers here make references to the C standard but forgot the POSIX standard, especially the specific behavior of the c99 (e.g. C compiler) command.
According to The Open Group Base Specifications Issue 7,
-I directory
Change the algorithm for searching for headers whose names are not absolute pathnames to look in the directory named by the directory pathname before looking in the usual places. Thus, headers whose names are enclosed in double-quotes ( "" ) shall be searched for first in the directory of the file with the #include line, then in directories named in -I options, and last in the usual places. For headers whose names are enclosed in angle brackets ( "<>" ), the header shall be searched for only in directories named in -I options and then in the usual places. Directories named in -I options shall be searched in the order specified. Implementations shall support at least ten instances of this option in a single c99 command invocation.
So, in a POSIX compliant environment, with a POSIX compliant C compiler, #include "file.h" is likely going to search for ./file.h first, where . is the directory where is the file with the #include statement, while #include <file.h>, is likely going to search for /usr/include/file.h first, where /usr/include is your system defined usual places for headers (it's seems not defined by POSIX).
The exact behavior of the preprocessor varies between compilers. The following answer applies for GCC and several other compilers.
#include <file.h> tells the compiler to search for the header in its "includes" directory, e.g. for MinGW the compiler would search for file.h in C:\MinGW\include\ or wherever your compiler is installed.
#include "file" tells the compiler to search the current directory (i.e. the directory in which the source file resides) for file.
You can use the -I flag for GCC to tell it that, when it encounters an include with angled brackets, it should also search for headers in the directory after -I. GCC will treat the directory after the flag as if it were the includes directory.
For instance, if you have a file called myheader.h in your own directory, you could say #include <myheader.h> if you called GCC with the flag -I . (indicating that it should search for includes in the current directory.)
Without the -I flag, you will have to use #include "myheader.h" to include the file, or move myheader.h to the include directory of your compiler.
GCC documentation says the following about the difference between the two:
Both user and system header files are included using the preprocessing directive ‘#include’. It has two variants:
#include <file>
This variant is used for system header files. It searches for a file named file in a standard list of system directories. You can prepend directories to this list with the -I option (see Invocation).
#include "file"
This variant is used for header files of your own program. It searches for a file named file first in the directory containing the current file, then in the quote directories and then the same directories used for <file>. You can prepend directories to the list of quote directories with the -iquote option.
The argument of ‘#include’, whether delimited with quote marks or angle brackets, behaves like a string constant in that comments are not recognized, and macro names are not expanded. Thus, #include <x/*y> specifies inclusion of a system header file named x/*y.
However, if backslashes occur within file, they are considered ordinary text characters, not escape characters. None of the character escape sequences appropriate to string constants in C are processed. Thus,#include "x\n\\y"specifies a filename containing three backslashes. (Some systems interpret ‘\’ as a pathname separator. All of these also interpret ‘/’ the same way. It is most portable to use only ‘/’.)
It is an error if there is anything (other than comments) on the line after the file name.
It does:
"mypath/myfile" is short for ./mypath/myfile
with . being either the directory of the file where the #include is contained in, and/or the current working directory of the compiler, and/or the default_include_paths
and
<mypath/myfile> is short for <defaultincludepaths>/mypath/myfile
If ./ is in <default_include_paths>, then it doesn't make a difference.
If mypath/myfile is in another include directory, the behavior is undefined.
The <file> include tells the preprocessor to search in -I directories and in predefined directories first, then in the .c file's directory. The "file" include tells the preprocessor to search the source file's directory first, and then revert to -I and predefined. All destinations are searched anyway, only the order of search is different.
The 2011 standard mostly discusses the include files in "16.2 Source file inclusion".
2 A preprocessing directive of the form
# include <h-char-sequence> new-line
searches a sequence of implementation-defined places for a header identified uniquely by the
specified sequence between the < and > delimiters, and causes the
replacement of that directive by the entire contents of the header.
How the places are specified or the header identified is
implementation-defined.
3 A preprocessing directive of the form
# include "q-char-sequence" new-line
causes the replacement of that directive by the entire contents of the source file identified by the
specified sequence between the " delimiters. The named source file is
searched for in an implementation-defined manner. If this search is
not supported, or if the search fails, the directive is reprocessed as
if it read
# include <h-char-sequence> new-line
with the identical contained sequence (including > characters, if any) from the original directive.
Note that "xxx" form degrades to <xxx> form if the file is not found. The rest is implementation-defined.
By the standard - yes, they are different:
A preprocessing directive of the form
#include <h-char-sequence> new-line
searches a sequence of implementation-defined places for a header identified uniquely by the specified sequence between the < and > delimiters, and causes the replacement of that directive by the entire contents of the header. How the places are specified or the header identified is implementation-defined.
A preprocessing directive of the form
#include "q-char-sequence" new-line
causes the replacement of that directive by the entire contents of the source file identified by the specified sequence between the " delimiters. The named source file is searched for in an implementation-defined manner. If this search is not supported, or if the search fails, the directive is reprocessed as if it read
#include <h-char-sequence> new-line
with the identical contained sequence (including > characters, if any) from the original
directive.
A preprocessing directive of the form
#include pp-tokens new-line
(that does not match one of the two previous forms) is permitted. The preprocessing tokens after include in the directive are processed just as in normal text. (Each identifier currently defined as a macro name is replaced by its replacement list of preprocessing tokens.) The directive resulting after all replacements shall match one of the two previous forms. The method by which a sequence of preprocessing tokens between a < and a > preprocessing token pair or a pair of " characters is combined into a single header name preprocessing token is implementation-defined.
Definitions:
h-char: any member of the source character set except the new-line character and >
q-char: any member of the source character set except the new-line character and "
Note that the standard does not tell any relation between the implementation-defined manners. The first form searches in one implementation-defined way, and the other in a (possibly other) implementation-defined way. The standard also specifies that certain include files shall be present (for example, <stdio.h>).
Formally you'd have to read the manual for your compiler, however normally (by tradition) the #include "..." form searches the directory of the file in which the #include was found first, and then the directories that the #include <...> form searches (the include path, eg system headers).
At least for GCC version <= 3.0, the angle-bracket form does not generate a dependency between the included file and the including one.
So if you want to generate dependency rules (using the GCC -M option for exemple), you must use the quoted form for the files that should be included in the dependency tree.
(See http://gcc.gnu.org/onlinedocs/cpp/Invocation.html )
For #include "" a compiler normally searches the folder of the file which contains that include and then the other folders. For #include <> the compiler does not search the current file's folder.
Thanks for the great answers, esp. Adam Stelmaszczyk and piCookie, and aib.
Like many programmers, I have used the informal convention of using the "myApp.hpp" form for application specific files, and the <libHeader.hpp> form for library and compiler system files, i.e. files specified in /I and the INCLUDE environment variable, for years thinking that was the standard.
However, the C standard states that the search order is implementation specific, which can make portability complicated. To make matters worse, we use jam, which automagically figures out where the include files are. You can use relative or absolute paths for your include files. i.e.
#include "../../MyProgDir/SourceDir1/someFile.hpp"
Older versions of MSVS required double backslashes (\\), but now that's not required. I don't know when it changed. Just use forward slashes for compatibility with 'nix (Windows will accept that).
If you are really worried about it, use "./myHeader.h" for an include file in the same directory as the source code (my current, very large project has some duplicate include file names scattered about--really a configuration management problem).
Here's the MSDN explanation copied here for your convenience).
Quoted form
The preprocessor searches for include files in this order:
In the same directory as the file that contains the #include statement.
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.
Along the path that's specified by each /I compiler option.
Along the paths that are specified by the INCLUDE environment variable.
Angle-bracket form
The preprocessor searches for include files in this order:
Along the path that's specified by each /I compiler option.
When compiling occurs on the command line, along the paths that are specified by the INCLUDE environment variable.
An #include with angle brackets will search an "implementation-dependent list of places" (which is a very complicated way of saying "system headers") for the file to be included.
An #include with quotes will just search for a file (and, "in an implementation-dependent manner", bleh). Which means, in normal English, it will try to apply the path/filename that you toss at it and will not prepend a system path or tamper with it otherwise.
Also, if #include "" fails, it is re-read as #include <> by the standard.
The gcc documentation has a (compiler specific) description which although being specific to gcc and not the standard, is a lot easier to understand than the attorney-style talk of the ISO standards.
Many of the answers here focus on the paths the compiler will search in order to find the file. While this is what most compilers do, a conforming compiler is allowed to be preprogrammed with the effects of the standard headers, and to treat, say, #include <list> as a switch, and it need not exist as a file at all.
This is not purely hypothetical. There is at least one compiler that work that way. Using #include <xxx> only with standard headers is recommended.
#include <abc.h>
is used to include standard library files. So the compiler will check in the locations where standard library headers are residing.
#include "xyz.h"
will tell the compiler to include user-defined header files. So the compiler will check for these header files in the current folder or -I defined folders.
#include <> is for predefined header files
If the header file is predefined then you would simply write the header file name in angular brackets, and it would look like this (assuming we have a predefined header file name iostream):
#include <iostream>
#include " " is for header files the programmer defines
If you (the programmer) wrote your own header file then you would write the header file name in quotes. So, suppose you wrote a header file called myfile.h, then this is an example of how you would use the include directive to include that file:
#include "myfile.h"
#include "filename" // User defined header
#include <filename> // Standard library header.
Example:
The filename here is Seller.h:
#ifndef SELLER_H // Header guard
#define SELLER_H // Header guard
#include <string>
#include <iostream>
#include <iomanip>
class Seller
{
private:
char name[31];
double sales_total;
public:
Seller();
Seller(char[], double);
char*getName();
#endif
In the class implementation (for example, Seller.cpp, and in other files that will use the file Seller.h), the header defined by the user should now be included, as follows:
#include "Seller.h"
In C++, include a file in two ways:
The first one is #include which tells the preprocessor to look for the file in the predefined default location.
This location is often an INCLUDE environment variable that denotes the path to include files.
And the second type is #include "filename" which tells the preprocessor to look for the file in the current directory first, then look for it in the predefined locations user have set up.
The #include <filename> is used when a system file is being referred to. That is a header file that can be found at system default locations like /usr/include or /usr/local/include. For your own files that needs to be included in another program you have to use the #include "filename" syntax.
The simple general rule is to use angled brackets to include header files that come with the compiler. Use double quotes to include any other header files. Most compilers do it this way.
1.9 — Header files explains in more detail about pre-processor directives. If you are a novice programmer, that page should help you understand all that. I learned it from here, and I have been following it at work.
#include <filename>
is used when you want to use the header file of the C/C++ system or compiler libraries. These libraries can be stdio.h, string.h, math.h, etc.
#include "path-to-file/filename"
is used when you want to use your own custom header file which is in your project folder or somewhere else.
For more information about preprocessors and header. Read C - Preprocessors.
#include <filename>
The preprocessor searches in an implementation-dependent manner. It tells the compiler to search directory where system header files are held.
This method usually use to find standard header files.
#include "filename"
This tell compiler to search header files where program is running. If it was failed it behave like #include <filename> and search that header file at where system header files stored.
This method usually used for identify user defined header files(header files which are created by user). There for don't use this if you want to call standard library because it takes more compiling time than #include <filename>.
Form 1 - #include < xxx >
First, looks for the presence of header file in the current directory from where directive is invoked. If not found, then it searches in the preconfigured list of standard system directories.
Form 2 - #include "xxx"
This looks for the presence of header file in the current directory from where directive is invoked.
The exact search directory list depends on the target system, how GCC is configured, and where it is installed.
You can find the search directory list of your GCC compiler by running it with -v option.
You can add additional directories to the search path by using - Idir, which causes dir to be searched after the current directory (for the quote form of the directive) and ahead of the standard system directories.
Basically, the form "xxx" is nothing but search in current directory; if not found falling back the form
#include <file>
Includes a file where the default include directory is.
#include "file"
Includes a file in the current directory in which it was compiled. Double quotes can specify a full file path to a different location as well.
the " < filename > " searches in standard C library locations
whereas "filename" searches in the current directory as well.
Ideally, you would use <...> for standard C libraries and "..." for libraries that you write and are present in the current directory.
In general the difference is where the preprocessor searches for the header file:
#include is a preprocessor directive to include header file. Both #include are used to add or include header file in the program, but first is to include system header files and later one for user defined header files.
#include <filename> is used to include the system library header file in the program, means the C/C++ preprocessor will search for the filename where the C library files are stored or predefined system header files are stored.
#include "filename" is used to include user defined header file in the program, means the C/C++ preprocessor will search for the filename in the current directory the program is in and then follows the search path used for the #include <filename>
Check the gcc docs gcc include files
"" will search ./ first. Then search the default include path.
You can use command like this to print the default include path:
gcc -v -o a a.c
Here are some examples to make thing more clear:
the code a.c works
// a.c
#include "stdio.h"
int main() {
int a = 3;
printf("a = %d\n", a);
return 0;
}
the code of b.c works too
// b.c
#include <stdio.h>
int main() {
int a = 3;
printf("a = %d\n", a);
return 0;
}
but when I create a new file named stdio.h in current directory
// stdio.h
inline int foo()
{
return 10;
}
a.c will generate compile error, but b.c still works
and "", <> can be used together with the same file name. since the search path priority is different.
so d.c also works
// d.c
#include <stdio.h>
#include "stdio.h"
int main()
{
int a = 0;
a = foo();
printf("a=%d\n", a);
return 0;
}
To see the search order on your system using gcc, based on current configuration , you can execute the following command. You can find more detail on this command here
cpp -v /dev/null -o /dev/null
Apple LLVM version 10.0.0 (clang-1000.10.44.2)
Target: x86_64-apple-darwin18.0.0
Thread model: posix InstalledDir: Library/Developer/CommandLineTools/usr/bin
"/Library/Developer/CommandLineTools/usr/bin/clang" -cc1 -triple
x86_64-apple-macosx10.14.0 -Wdeprecated-objc-isa-usage
-Werror=deprecated-objc-isa-usage -E -disable-free -disable-llvm-verifier -discard-value-names -main-file-name null -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -fno-strict-return -masm-verbose -munwind-tables -target-cpu penryn -dwarf-column-info -debugger-tuning=lldb -target-linker-version 409.12 -v -resource-dir /Library/Developer/CommandLineTools/usr/lib/clang/10.0.0 -isysroot
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk
-I/usr/local/include -fdebug-compilation-dir /Users/hogstrom -ferror-limit 19 -fmessage-length 80 -stack-protector 1 -fblocks -fencode-extended-block-signature -fobjc-runtime=macosx-10.14.0 -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -traditional-cpp -o - -x c /dev/null
clang -cc1 version 10.0.0 (clang-1000.10.44.2) default target x86_64-apple-darwin18.0.0 ignoring
nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/local/include"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/Library/Developer/CommandLineTools/usr/lib/clang/10.0.0/include
/Library/Developer/CommandLineTools/usr/include
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks (framework directory)
End of search list.
The implementation-defined warnings generated by the compiler can (and will) treat system libraries differently than program libraries.
So
#include <myFilename>
-- which in effect declares that myFilename is in the system library location -- may well (and probably will) hide dead code and unused variable warnings etc, that would show up when you use:
#include "myFilename"
There exists two ways to write #include statement.These are:
#include"filename"
#include<filename>
The meaning of each form is
#include"mylib.h"
This command would look for the file mylib.h in the current directory as well as the specified list of directories as mentioned n the include search path that might have been set up.
#include<mylib.h>
This command would look for the file mylib.h in the specified list of directories only.
The include search path is nothing but a list of directories that would be searched for the file being included.Different C compilers let you set the search path in different manners.
In a "working directory" I have a lot of *.cpp and *.h files that #include each other and files from subdirectories.
For example:
#include "first.h"
#include "second.h"
#include "dir1/third.h"
#include "dir2/fourth.h"
In my own directory (that is different from the "working" directory) I would like to create a new *.cpp and *.h file that includes one of the files from the "working" directory. For example:
#include "/root/workingdirectory/first.h"
However, it does not work. Because "first.h" might include "second.h" and "second.h" is not located in my directory. Is there a way to tell the compiler that it needs to search included files not in the current but in the working directory: /root/workingdirectory/?
To make it even more complex, dir1 and dir2 are not located in my working directory. They are located in /root/workingdirectory2/. So, my second question is if it is possible to resolve this problem by letting compiler know that subdirectories are located somewhere else?
I also need to add, that I do not use any environment for development and compile from the command line (using g++).
As you've already been told, it's useful to read the manual - specifically this chapter - and even more specifically right here.
Specifically, you want
g++ -I/root/workingdirectory -I/root/workingdirectory2
Note also the documentation on #include directive syntax, described here as:
2.1 Include Syntax
Both user and system header files are included using the preprocessing
directive #include. It has two variants:
#include <file>
This variant is used for system header files. It searches for a file named file in a standard list of system directories. You can prepend directories to this list with the -I
option (see Invocation).
#include "file"
This variant is used for header files of your own program. It searches for a file named file first in the directory
containing the current file, then in the quote directories and then
the same directories used for <file>. You can prepend directories to
the list of quote directories with the -iquote option. The argument of
#include, whether delimited with quote marks or angle brackets,
behaves like a string constant in that comments are not recognized,
and macro names are not expanded. Thus,#include <x/*y> specifies
inclusion of a system header file named x/*y.
However, if backslashes occur within file, they are considered
ordinary text characters, not escape characters. None of the character
escape sequences appropriate to string constants in C are processed.
Thus, #include "x\n\\y" specifies a filename containing three
backslashes. (Some systems interpret \ as a pathname separator. All
of these also interpret / the same way. It is most portable to use
only /.)
It is an error if there is anything (other than comments) on the line
after the file name.
So for example
#include "first.h"
will start looking in the same directory as the .cpp file containing this directive (or take a relative path as relative to this directory).
If you want to use the include path (specified by -I) you should use
#include <dir1/third.h>
Usual practice is to use the #include "local.h" form for headers inside a library/package/module (however you've chosen to organize that), and the #include <external.h> form for headers from external/3rd-party or system libraries.
Read The Fine Manual
It's there for everyone to read. You even have a choice of what to use (I'd go with the first):
-Idir
Add the directory dir to the head of the list of directories to be searched for header files. This can be used to override a system header file, substituting your own version, since these directories are searched before the system header file directories. However, you should not use this option to add directories that contain vendor-supplied system header files (use -isystem for that). If you use more than one -I option, the directories are scanned in left-to-right order; the standard system directories come after.
If a standard system include directory, or a directory specified with -isystem, is also specified with -I, the -I option is ignored. The directory is still searched but as a system directory at its normal position in the system include chain. This is to ensure that GCC's procedure to fix buggy system headers and the ordering for the include_next directive are not inadvertently changed. If you really need to change the search order for system directories, use the -nostdinc and/or -isystem options.
-iquotedir
Add the directory dir to the head of the list of directories to be searched for header files only for the case of #include "file"; they are not searched for #include <file>, otherwise just like -I.
For gcc it is the -I option for header includes. For the .cpp files you just need those to appear as an argument to the gcc command.
Every C/C++ compiler (g++, gcc, MinGW, clang, e.t.c.) has a folder called "include" in it's root path where it automatically looks for header files. If you use MinGW, it would be in, for example: "C:\MinGW\include". Just save your header to the include folder like this: C:\MinGW\include\header1.h or C:\MinGW\include\LibGUI\Window.h
I'm using a library written by others which is kinda based on C for C++ usage -I think-. All inclusions used inside the headers or source files are in the form <> instead of "" even though they are not standard library files. My compiler doesn't recognize them and returns error "file not found"
An example of the problem is inside the following header:
#ifndef _ga_ga_h_
#define _ga_ga_h_
// Make sure that we get the configuration into each of the galib components
// that will be used.
#include <ga/gaconfig.h>
// These are the headers for all of the genetic algorithm classes.
#include <ga/GASimpleGA.h>
#include <ga/GASStateGA.h>
#include <ga/GAIncGA.h>
#include <ga/GADemeGA.h>
#include <ga/GADCrowdingGA.h>
// Here we include the headers for all of the various genome types.
#include <ga/GA1DBinStrGenome.h>
#include <ga/GA2DBinStrGenome.h>
#include <ga/GA3DBinStrGenome.h>
#include <ga/GABin2DecGenome.h>
I include that header inside my program using #include "ga.h" but it is very hard to change inside every header/source file in the library.
Is there a way to make the compiler use <> as if they were ""?
I tried adding the paths to "Addition include directories"from Project properties (I'm using Visual Studio), Many inclusions' errors disappeared but around 30 persisted. The strange thing is that they are in a file called "c1xx" but i don't have that file!!
thanks,
The definition is somewhat that <> is used for "system" header files, usually found in locations like /usr/include (on Unix-like systems) and "" is used for local header files. When you compile your code, you can indicate the location of additional directories containing header files e.g. using the -I option when using GCC. Check your compiler's documentation for the setting needed
So, e.g. on Linux and GCC, if your "ga" directory is in /usr/local/include/ga, you would use cc -I /usr/local/include.
This indeed looks like a problem of telling the compiler where to look for the included header files. As mentioned in the other answers, when you do a #include <header.h>, header.h must be in one of the include search paths - either the system includes, or the additional paths that you are telling the compiler to look for headers. In Linux/g++ (as mentioned in the other answers here), you do that by passing in the the additional search paths in the -I flag. The compilation command would look something like:
g++ -I/additional/header/search/path -o a.out your_file.cpp
Since you are using visual studio and the MSVC compiler, the equivalent would be the /I flag, and the compilation command would look something like:
CL /I\additional\header\path your_file.cpp
I am assuming you are using Visual Studio - you can also configure that from the project properties. Go to Configuration Properties > C/C++ > General and modify Additional Include Directories. Refer these for more info:
Setting C++ compiler and build properties
Additional include directories
First about the difference between <header> and <file>. The standards (both C and C++) only specifies that
#include <header>
includes an header named header and that
#include "file"
includes a source file named file, if none is found an header named file is included instead.
What are headers and how they differ from source files is left to the implementation. In practice they are files as well. So #include <header> is looking for a file in some places, #include "file" is looking for a file in some other places and if not found at the same places as for #include <file>.
AFAIK all compilers
are able to search for source files in the directory of the file containing the include directive
are able to be given a list of directories to search for headers before their default search path.
ISTR that Visual C++ is also searching for a source file in the directories of files indirectly including it. (I can't confirm currently if my memory is good; that behavior is AFAIK unachievable with other compilers so I never relied on it and -- by luck? -- it never resulted in a different behavior for my programs).
Obviously that behavior is more or less customizable. For instance with g++ is possible to:
disable the search of a source file in the directory of the file containing the include directive (with -I-, note that -I- is deprecated since gcc 4.0 -- 2005 -- when -iquote has been introduced and there is no non-deprecated way to achieve this)
to add a list of directories to search for source files and not for headers (with -iquote and it's an effect of -I- as well)
to give a list of directories to search for headers after the default list of directories (with -idirafter)
to give a list of directories to search for headers which are processed specially (with -isystem; less warnings are given for constructs in those files which help when using the "treat warnings as errors" flags, they aren't considered as dependencies with -MM and -MMD which usually is a nuisance)
Now for your problem. The library has been visibly designed to be used by adding the directory containing the directory ga to the include path. That should be enough as I'm unaware of any compiler modifying its search path for headers depending on how the file including the header has been included.
Note that c1xx is probably the name of the compiler executable, not the name of a file trying to include another (again, I'm not in position to ensure that's the case now, but compare with cc1plus which is the name of the compiler for GCC -- g++ is a driver handling several things and executing cc1plus to handle the compilation of C++ code)
If you do on the command line:
echo | gcc -v -E -x c++ -
You will get an output with the default include directories for C++. Those are the built in system's include search paths.
If you compile with g++ -I/some/dir -o foo foo.cpp, you are adding an additional include search path (/some/dir) to the compilation.
Headers in the above locations can be found by include directives like #include <header>. #include "header" directives can also find headers in those locations, but they are more relevant for the following case.
When you do #include "header", your compiler will first try to find "header" relative to the directory of foo.cpp if it includes it, despite foo.cpp directory being in search paths or not. If it doesn't find it there, it will try to look up in the include search paths. So this one is more relevant for headers that are more tied to a specific .cpp file and you don't want additional include search paths added to the compilation, or if you prefer to use include directives with relative paths.
So if you use #include <header>, header must be in some of the include search paths, system or /some/dir from -I flag. If header is relative to foo.cpp, but not in search paths, compilation will fail.
If you use #include "header" and header is not in any of the include search paths, it can still be found relative to foo.cpp location.
What is the difference between using angle brackets and quotes in an include directive?
#include <filename>
#include "filename"
What differs is the locations in which the preprocessor searches for the file to be included.
#include <filename> The preprocessor searches in an implementation-defined manner, normally in directories pre-designated by the compiler/IDE. This method is normally used to include header files for the C standard library and other header files associated with the target platform.
#include "filename" The preprocessor also searches in an implementation-defined manner, but one that is normally used to include programmer-defined header files and typically includes same directory as the file containing the directive (unless an absolute path is given).
For GCC, a more complete description is available in the GCC documentation on search paths.
The only way to know is to read your implementation's documentation.
In the C standard, section 6.10.2, paragraphs 2 to 4 state:
A preprocessing directive of the form
#include <h-char-sequence> new-line
searches a sequence of implementation-defined places for a header identified uniquely by the specified sequence between the < and > delimiters, and causes the replacement of that directive by the entire contents of the header. How the places are specified or the header identified is implementation-defined.
A preprocessing directive of the form
#include "q-char-sequence" new-line
causes the replacement of that directive by the entire contents of the source file identified by the specified sequence between the " delimiters. The named source file is searched for in an implementation-defined manner. If this search is not supported, or if the search fails, the directive is reprocessed as if it read
#include <h-char-sequence> new-line
with the identical contained sequence (including > characters, if any) from the original
directive.
A preprocessing directive of the form
#include pp-tokens new-line
(that does not match one of the two previous forms) is permitted. The preprocessing tokens after include in the directive are processed just as in normal text. (Each identifier currently defined as a macro name is replaced by its replacement list of preprocessing tokens.) The directive resulting after all replacements shall match one of the two previous forms. The method by which a sequence of preprocessing tokens between a < and a > preprocessing token pair or a pair of " characters is combined into a single header name preprocessing token is implementation-defined.
Definitions:
h-char: any member of the source character set except the new-line character and >
q-char: any member of the source character set except the new-line character and "
The sequence of characters between < and > uniquely refer to a header, which isn't necessarily a file. Implementations are pretty much free to use the character sequence as they wish. (Mostly, however, just treat it as a file name and do a search in the include path, as the other posts state.)
If the #include "file" form is used, the implementation first looks for a file of the given name, if supported. If not (supported), or if the search fails, the implementation behaves as though the other (#include <file>) form was used.
Also, a third form exists and is used when the #include directive doesn't match either of the forms above. In this form, some basic preprocessing (such as macro expansion) is done on the "operands" of the #include directive, and the result is expected to match one of the two other forms.
Some good answers here make references to the C standard but forgot the POSIX standard, especially the specific behavior of the c99 (e.g. C compiler) command.
According to The Open Group Base Specifications Issue 7,
-I directory
Change the algorithm for searching for headers whose names are not absolute pathnames to look in the directory named by the directory pathname before looking in the usual places. Thus, headers whose names are enclosed in double-quotes ( "" ) shall be searched for first in the directory of the file with the #include line, then in directories named in -I options, and last in the usual places. For headers whose names are enclosed in angle brackets ( "<>" ), the header shall be searched for only in directories named in -I options and then in the usual places. Directories named in -I options shall be searched in the order specified. Implementations shall support at least ten instances of this option in a single c99 command invocation.
So, in a POSIX compliant environment, with a POSIX compliant C compiler, #include "file.h" is likely going to search for ./file.h first, where . is the directory where is the file with the #include statement, while #include <file.h>, is likely going to search for /usr/include/file.h first, where /usr/include is your system defined usual places for headers (it's seems not defined by POSIX).
The exact behavior of the preprocessor varies between compilers. The following answer applies for GCC and several other compilers.
#include <file.h> tells the compiler to search for the header in its "includes" directory, e.g. for MinGW the compiler would search for file.h in C:\MinGW\include\ or wherever your compiler is installed.
#include "file" tells the compiler to search the current directory (i.e. the directory in which the source file resides) for file.
You can use the -I flag for GCC to tell it that, when it encounters an include with angled brackets, it should also search for headers in the directory after -I. GCC will treat the directory after the flag as if it were the includes directory.
For instance, if you have a file called myheader.h in your own directory, you could say #include <myheader.h> if you called GCC with the flag -I . (indicating that it should search for includes in the current directory.)
Without the -I flag, you will have to use #include "myheader.h" to include the file, or move myheader.h to the include directory of your compiler.
GCC documentation says the following about the difference between the two:
Both user and system header files are included using the preprocessing directive ‘#include’. It has two variants:
#include <file>
This variant is used for system header files. It searches for a file named file in a standard list of system directories. You can prepend directories to this list with the -I option (see Invocation).
#include "file"
This variant is used for header files of your own program. It searches for a file named file first in the directory containing the current file, then in the quote directories and then the same directories used for <file>. You can prepend directories to the list of quote directories with the -iquote option.
The argument of ‘#include’, whether delimited with quote marks or angle brackets, behaves like a string constant in that comments are not recognized, and macro names are not expanded. Thus, #include <x/*y> specifies inclusion of a system header file named x/*y.
However, if backslashes occur within file, they are considered ordinary text characters, not escape characters. None of the character escape sequences appropriate to string constants in C are processed. Thus,#include "x\n\\y"specifies a filename containing three backslashes. (Some systems interpret ‘\’ as a pathname separator. All of these also interpret ‘/’ the same way. It is most portable to use only ‘/’.)
It is an error if there is anything (other than comments) on the line after the file name.
It does:
"mypath/myfile" is short for ./mypath/myfile
with . being either the directory of the file where the #include is contained in, and/or the current working directory of the compiler, and/or the default_include_paths
and
<mypath/myfile> is short for <defaultincludepaths>/mypath/myfile
If ./ is in <default_include_paths>, then it doesn't make a difference.
If mypath/myfile is in another include directory, the behavior is undefined.
The <file> include tells the preprocessor to search in -I directories and in predefined directories first, then in the .c file's directory. The "file" include tells the preprocessor to search the source file's directory first, and then revert to -I and predefined. All destinations are searched anyway, only the order of search is different.
The 2011 standard mostly discusses the include files in "16.2 Source file inclusion".
2 A preprocessing directive of the form
# include <h-char-sequence> new-line
searches a sequence of implementation-defined places for a header identified uniquely by the
specified sequence between the < and > delimiters, and causes the
replacement of that directive by the entire contents of the header.
How the places are specified or the header identified is
implementation-defined.
3 A preprocessing directive of the form
# include "q-char-sequence" new-line
causes the replacement of that directive by the entire contents of the source file identified by the
specified sequence between the " delimiters. The named source file is
searched for in an implementation-defined manner. If this search is
not supported, or if the search fails, the directive is reprocessed as
if it read
# include <h-char-sequence> new-line
with the identical contained sequence (including > characters, if any) from the original directive.
Note that "xxx" form degrades to <xxx> form if the file is not found. The rest is implementation-defined.
By the standard - yes, they are different:
A preprocessing directive of the form
#include <h-char-sequence> new-line
searches a sequence of implementation-defined places for a header identified uniquely by the specified sequence between the < and > delimiters, and causes the replacement of that directive by the entire contents of the header. How the places are specified or the header identified is implementation-defined.
A preprocessing directive of the form
#include "q-char-sequence" new-line
causes the replacement of that directive by the entire contents of the source file identified by the specified sequence between the " delimiters. The named source file is searched for in an implementation-defined manner. If this search is not supported, or if the search fails, the directive is reprocessed as if it read
#include <h-char-sequence> new-line
with the identical contained sequence (including > characters, if any) from the original
directive.
A preprocessing directive of the form
#include pp-tokens new-line
(that does not match one of the two previous forms) is permitted. The preprocessing tokens after include in the directive are processed just as in normal text. (Each identifier currently defined as a macro name is replaced by its replacement list of preprocessing tokens.) The directive resulting after all replacements shall match one of the two previous forms. The method by which a sequence of preprocessing tokens between a < and a > preprocessing token pair or a pair of " characters is combined into a single header name preprocessing token is implementation-defined.
Definitions:
h-char: any member of the source character set except the new-line character and >
q-char: any member of the source character set except the new-line character and "
Note that the standard does not tell any relation between the implementation-defined manners. The first form searches in one implementation-defined way, and the other in a (possibly other) implementation-defined way. The standard also specifies that certain include files shall be present (for example, <stdio.h>).
Formally you'd have to read the manual for your compiler, however normally (by tradition) the #include "..." form searches the directory of the file in which the #include was found first, and then the directories that the #include <...> form searches (the include path, eg system headers).
At least for GCC version <= 3.0, the angle-bracket form does not generate a dependency between the included file and the including one.
So if you want to generate dependency rules (using the GCC -M option for exemple), you must use the quoted form for the files that should be included in the dependency tree.
(See http://gcc.gnu.org/onlinedocs/cpp/Invocation.html )
For #include "" a compiler normally searches the folder of the file which contains that include and then the other folders. For #include <> the compiler does not search the current file's folder.
Thanks for the great answers, esp. Adam Stelmaszczyk and piCookie, and aib.
Like many programmers, I have used the informal convention of using the "myApp.hpp" form for application specific files, and the <libHeader.hpp> form for library and compiler system files, i.e. files specified in /I and the INCLUDE environment variable, for years thinking that was the standard.
However, the C standard states that the search order is implementation specific, which can make portability complicated. To make matters worse, we use jam, which automagically figures out where the include files are. You can use relative or absolute paths for your include files. i.e.
#include "../../MyProgDir/SourceDir1/someFile.hpp"
Older versions of MSVS required double backslashes (\\), but now that's not required. I don't know when it changed. Just use forward slashes for compatibility with 'nix (Windows will accept that).
If you are really worried about it, use "./myHeader.h" for an include file in the same directory as the source code (my current, very large project has some duplicate include file names scattered about--really a configuration management problem).
Here's the MSDN explanation copied here for your convenience).
Quoted form
The preprocessor searches for include files in this order:
In the same directory as the file that contains the #include statement.
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.
Along the path that's specified by each /I compiler option.
Along the paths that are specified by the INCLUDE environment variable.
Angle-bracket form
The preprocessor searches for include files in this order:
Along the path that's specified by each /I compiler option.
When compiling occurs on the command line, along the paths that are specified by the INCLUDE environment variable.
An #include with angle brackets will search an "implementation-dependent list of places" (which is a very complicated way of saying "system headers") for the file to be included.
An #include with quotes will just search for a file (and, "in an implementation-dependent manner", bleh). Which means, in normal English, it will try to apply the path/filename that you toss at it and will not prepend a system path or tamper with it otherwise.
Also, if #include "" fails, it is re-read as #include <> by the standard.
The gcc documentation has a (compiler specific) description which although being specific to gcc and not the standard, is a lot easier to understand than the attorney-style talk of the ISO standards.
Many of the answers here focus on the paths the compiler will search in order to find the file. While this is what most compilers do, a conforming compiler is allowed to be preprogrammed with the effects of the standard headers, and to treat, say, #include <list> as a switch, and it need not exist as a file at all.
This is not purely hypothetical. There is at least one compiler that work that way. Using #include <xxx> only with standard headers is recommended.
#include <abc.h>
is used to include standard library files. So the compiler will check in the locations where standard library headers are residing.
#include "xyz.h"
will tell the compiler to include user-defined header files. So the compiler will check for these header files in the current folder or -I defined folders.
#include <> is for predefined header files
If the header file is predefined then you would simply write the header file name in angular brackets, and it would look like this (assuming we have a predefined header file name iostream):
#include <iostream>
#include " " is for header files the programmer defines
If you (the programmer) wrote your own header file then you would write the header file name in quotes. So, suppose you wrote a header file called myfile.h, then this is an example of how you would use the include directive to include that file:
#include "myfile.h"
#include "filename" // User defined header
#include <filename> // Standard library header.
Example:
The filename here is Seller.h:
#ifndef SELLER_H // Header guard
#define SELLER_H // Header guard
#include <string>
#include <iostream>
#include <iomanip>
class Seller
{
private:
char name[31];
double sales_total;
public:
Seller();
Seller(char[], double);
char*getName();
#endif
In the class implementation (for example, Seller.cpp, and in other files that will use the file Seller.h), the header defined by the user should now be included, as follows:
#include "Seller.h"
In C++, include a file in two ways:
The first one is #include which tells the preprocessor to look for the file in the predefined default location.
This location is often an INCLUDE environment variable that denotes the path to include files.
And the second type is #include "filename" which tells the preprocessor to look for the file in the current directory first, then look for it in the predefined locations user have set up.
The #include <filename> is used when a system file is being referred to. That is a header file that can be found at system default locations like /usr/include or /usr/local/include. For your own files that needs to be included in another program you have to use the #include "filename" syntax.
The simple general rule is to use angled brackets to include header files that come with the compiler. Use double quotes to include any other header files. Most compilers do it this way.
1.9 — Header files explains in more detail about pre-processor directives. If you are a novice programmer, that page should help you understand all that. I learned it from here, and I have been following it at work.
#include <filename>
is used when you want to use the header file of the C/C++ system or compiler libraries. These libraries can be stdio.h, string.h, math.h, etc.
#include "path-to-file/filename"
is used when you want to use your own custom header file which is in your project folder or somewhere else.
For more information about preprocessors and header. Read C - Preprocessors.
#include <filename>
The preprocessor searches in an implementation-dependent manner. It tells the compiler to search directory where system header files are held.
This method usually use to find standard header files.
#include "filename"
This tell compiler to search header files where program is running. If it was failed it behave like #include <filename> and search that header file at where system header files stored.
This method usually used for identify user defined header files(header files which are created by user). There for don't use this if you want to call standard library because it takes more compiling time than #include <filename>.
Form 1 - #include < xxx >
First, looks for the presence of header file in the current directory from where directive is invoked. If not found, then it searches in the preconfigured list of standard system directories.
Form 2 - #include "xxx"
This looks for the presence of header file in the current directory from where directive is invoked.
The exact search directory list depends on the target system, how GCC is configured, and where it is installed.
You can find the search directory list of your GCC compiler by running it with -v option.
You can add additional directories to the search path by using - Idir, which causes dir to be searched after the current directory (for the quote form of the directive) and ahead of the standard system directories.
Basically, the form "xxx" is nothing but search in current directory; if not found falling back the form
#include <file>
Includes a file where the default include directory is.
#include "file"
Includes a file in the current directory in which it was compiled. Double quotes can specify a full file path to a different location as well.
the " < filename > " searches in standard C library locations
whereas "filename" searches in the current directory as well.
Ideally, you would use <...> for standard C libraries and "..." for libraries that you write and are present in the current directory.
In general the difference is where the preprocessor searches for the header file:
#include is a preprocessor directive to include header file. Both #include are used to add or include header file in the program, but first is to include system header files and later one for user defined header files.
#include <filename> is used to include the system library header file in the program, means the C/C++ preprocessor will search for the filename where the C library files are stored or predefined system header files are stored.
#include "filename" is used to include user defined header file in the program, means the C/C++ preprocessor will search for the filename in the current directory the program is in and then follows the search path used for the #include <filename>
Check the gcc docs gcc include files
"" will search ./ first. Then search the default include path.
You can use command like this to print the default include path:
gcc -v -o a a.c
Here are some examples to make thing more clear:
the code a.c works
// a.c
#include "stdio.h"
int main() {
int a = 3;
printf("a = %d\n", a);
return 0;
}
the code of b.c works too
// b.c
#include <stdio.h>
int main() {
int a = 3;
printf("a = %d\n", a);
return 0;
}
but when I create a new file named stdio.h in current directory
// stdio.h
inline int foo()
{
return 10;
}
a.c will generate compile error, but b.c still works
and "", <> can be used together with the same file name. since the search path priority is different.
so d.c also works
// d.c
#include <stdio.h>
#include "stdio.h"
int main()
{
int a = 0;
a = foo();
printf("a=%d\n", a);
return 0;
}
To see the search order on your system using gcc, based on current configuration , you can execute the following command. You can find more detail on this command here
cpp -v /dev/null -o /dev/null
Apple LLVM version 10.0.0 (clang-1000.10.44.2)
Target: x86_64-apple-darwin18.0.0
Thread model: posix InstalledDir: Library/Developer/CommandLineTools/usr/bin
"/Library/Developer/CommandLineTools/usr/bin/clang" -cc1 -triple
x86_64-apple-macosx10.14.0 -Wdeprecated-objc-isa-usage
-Werror=deprecated-objc-isa-usage -E -disable-free -disable-llvm-verifier -discard-value-names -main-file-name null -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -fno-strict-return -masm-verbose -munwind-tables -target-cpu penryn -dwarf-column-info -debugger-tuning=lldb -target-linker-version 409.12 -v -resource-dir /Library/Developer/CommandLineTools/usr/lib/clang/10.0.0 -isysroot
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk
-I/usr/local/include -fdebug-compilation-dir /Users/hogstrom -ferror-limit 19 -fmessage-length 80 -stack-protector 1 -fblocks -fencode-extended-block-signature -fobjc-runtime=macosx-10.14.0 -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -traditional-cpp -o - -x c /dev/null
clang -cc1 version 10.0.0 (clang-1000.10.44.2) default target x86_64-apple-darwin18.0.0 ignoring
nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/local/include"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/Library/Developer/CommandLineTools/usr/lib/clang/10.0.0/include
/Library/Developer/CommandLineTools/usr/include
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks (framework directory)
End of search list.
The implementation-defined warnings generated by the compiler can (and will) treat system libraries differently than program libraries.
So
#include <myFilename>
-- which in effect declares that myFilename is in the system library location -- may well (and probably will) hide dead code and unused variable warnings etc, that would show up when you use:
#include "myFilename"
There exists two ways to write #include statement.These are:
#include"filename"
#include<filename>
The meaning of each form is
#include"mylib.h"
This command would look for the file mylib.h in the current directory as well as the specified list of directories as mentioned n the include search path that might have been set up.
#include<mylib.h>
This command would look for the file mylib.h in the specified list of directories only.
The include search path is nothing but a list of directories that would be searched for the file being included.Different C compilers let you set the search path in different manners.
This question already has answers here:
What is the difference between #include <filename> and #include "filename"?
(30 answers)
Closed 8 years ago.
I am new to C++.
What is the difference between including the c++ header files using "" and <>
I am trying to use some of the header files form an open source library. All header files in that library are included using <>. Now when I do the same in my header file, its failing at compile time.
<> looks firstly in the header path for the header file whereas "" looks firstly in the current directory of the file for the header.
The distinction is very largely implementation defined; the "..." form
should look first in the place where the file which includes it is
situated; the <...> no. Beyond that, both look in an implementation
defined list of places, with the additional requirement that if the
compiler doesn't find a "..." form in any of the expected places, it
reprocesses the include as if it were a <...> form.
In practice, all of the compilers I know build a list of places using
the -I or /I options, followed by a number of "standard" and
compiler defined places. This list is for <...>; "..." is searched
in the same directory as the including file, then treated as a <...>.
(Some compilers, at least, also have options to add to the list for
"...".)
I'm not sure what's happening with regards to the library. Normally,
when using a third party library, you have to add one or more -I or
/I options to tell the compiler where to find its headers. Once
you've done that, both your code and the library code should find all of
the necessary headers. The one case I can think of where an include
might work in a library header, and not in your own headers, is a
"..." style include in a library header which was included from
another library header, using a path specifier, e.g.:
LibraryFile1.hpp:
#include "Subdir/LibraryFile2.hpp"
LibraryFile2.hpp:
#include "LibraryFile3.hpp"
You will have told the compiler to look for the headers (using a -I
option) in something like LibraryRoot/include, which is where
LibraryFile1.hpp is located; LibraryFile2.hpp is relative to this
location, and in LibraryFile2.hpp, the compiler finds
LibraryFile3.hpp because it is in the same directory as the file which
includes it. If you try to include LibraryFile3.hpp directly,
however, the compiler won't find it.
File includes between <> are looked for in your compiler's path, whereas "" is looking relatively to your current directory (or absolute if you specify a path that starts with / or c:\ but this is not recommended)
On Unix systems, by default the path contains /usr/include. This path may be completed by adding -Isome_directory for it to search in it.
For example, if you have your file test.c and you want to include include/test.h, you have different choices:
Write #include "include/test.h", which will look relatively from the directory of the compiled file.
Write #include <test.h>, but this time you will need to specify -Iinclude to the compiler to add the ./include directory to the compiler's path.
Note, however, that some compilers accept the "" notation for lookups in the path, but that always confused me and is a bad thing to do.
The quotes mean include from local folder and the <> mean to include from another directory specified using a flag to g++ or MSVC or whatever compiler you are using or system headers.
<> looks in the default directory for include files, "" looks in the current directory and than in the default directory
This question is a duplicate of Question 21593. None of the above answers above are totally correct. Like many programmers, I have used the informal convention of using the "myApp.hpp" form for application specific files, and the form for library and compiler system files, i.e. files specified in /I and the INCLUDE environment variable. However, the C standard states that the search order is implementation specific.
Here's the msdn explanation copied here for your convenience).
Quoted form
The preprocessor 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.
Angle-bracket form
The preprocessor searches for include files in this order:
1. Along the path that's specified by each /I compiler option.
2. When compiling occurs on the command line, along the paths that are specified by the INCLUDE
environment variable.
Including a file using <> will tell the compiler to look for those files in environment-defined inclusion folders. Those folders can be standard system folders, or defined by your Makefile if you use one, etc. Using "", the compiler will look for inclusion files only in the source file's path.
So you can use "" and use absolute paths or the path which is relative to the source file you try to include in, or you can use <> after defining your inclusion folders, and just specify the name of the header file to include.
IMHO, the second option is better, especially if you use a lot of headers, or multiple libraries, etc...
To define inclusion folders at compilation time : gcc -I ... (man gcc!)