By quest49


2008-08-22 01:40:06 8 Comments

In the C and C++ programming languages, what is the difference between using angle brackets and using quotes in an include statement, as follows?

  1. #include <filename>
  2. #include "filename"

27 comments

@Darshan L 2018-08-17 09:59:40

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

@Jonathan Leffler 2019-07-13 05:27:20

If you decide to answer an older question that has well established and correct answers, adding a new answer late in the day may not get you any credit. If you have some distinctive new information, or you're convinced the other answers are all wrong, by all means add a new answer, but 'yet another answer' giving the same basic information a long time after the question was asked usually won't earn you much credit.

@personal_cloud 2019-07-13 05:36:49

@Jonathan Leffler Can you point me to the "well established" answer that you feel is as concise and accurate as Darshan's answer?

@Jonathan Leffler 2019-07-13 06:05:27

The description of the #include "header.h" form is not accurate, @personal_cloud. I consider the answer by piCookie and Yann Droneaud to be most relevant as they identify where their information comes from. I don't find the top-voted answer to be entirely satisfactory, either.

@Neonit 2019-08-01 15:37:38

Why is this answer shown on top, while two answers further down there is a 650+ votes one? This answer confused me, because it doesn't match the behavior observed by me. This might be, because the last sentence is broken due to not escaping angle brackets. I'm not sure what it is supposed to mean.

@S. M. AMRAN 2017-01-07 04:39:50

#include <filename>     (1)     
#include "filename"     (2)

#include includes source file, identified by filename, into the current source file at the line immediately after the directive.

The first version of the directive searches only standard include directories. The standard C++ library, as well as standard C library, is implicitly included in standard include directories. The standard include directories can be controlled by the user through compiler options.

The second version first searches the directory where the current file resides and, only if the file is not found, searches the standard include directories.

In the case the file is not found, the program is ill-formed.

@Jonathan Leffler 2019-07-13 05:26:29

Welcome to Stack Overflow. If you decide to answer an older question that has well established and correct answers, adding a new answer late in the day may not get you any credit. If you have some distinctive new information, or you're convinced the other answers are all wrong, by all means add a new answer, but 'yet another answer' giving the same basic information a long time after the question was asked usually won't earn you much credit.

@piCookie 2008-09-16 21:06:23

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 "

@Alexander Malakhov 2012-10-10 03:48:31

Relevant: implementation in g++ and in visual c++

@onmyway133 2013-02-04 03:45:17

@piCookie both <filename> and "filename" search for implementation-defined places. So what is the difference ?

@piCookie 2013-02-05 16:38:13

@entropy: In a forum like this, it is not possible to answer your question. An answer that would be correct for one particular compiler could be entirely wrong for another. Each particular implementation / compiler should be obligated to spell out the difference, and that is the only reliable way to know. Several other answers have given examples, and perhaps your implementation is mentioned in one of those.

@Stefan 2013-08-23 19:12:28

@piCookie but you could say that angle brackets are inspecting the INCLUDE_PATH, where "" doesn't. so angle brackets are introducing a search path but aren't cwd at all. actually there is no difference, if you reduce it to the point, that <> only searches on the standard include path.

@piCookie 2013-08-25 00:22:44

@Stefan, I'm just quoting the standard which does not say anything about INCLUDE_PATH. Your implementation may do that, and mine may not. The original question was generically C and not specifically gcc (which I don't think uses INCLUDE_PATH) or Microsoft C (which I think does) or any other, so it can not be answered generically but instead each implementation's documentation must be referenced.

@Stefan 2013-08-25 12:28:44

@piCookie no. INCLUDE_PATH was more meant to be as a variable containing the standard paths for the compiler, not a vendor specific implementation detail.

@vargonian 2014-04-29 17:51:42

As with all of these situations, concrete examples (especially of common scenarios) are greatly useful and equally appreciated. Needlessly obtuse generic answers don't have as much practical use.

@Rudy Velthuis 2014-06-08 17:55:01

I don't exactly know how this is in C, bit if I read the standard quotation above, the sequence between < and > does not necessarily have to be a file name. Anything that uniquely defines a header will do. In C++, this means that <algorithm> does not necessarily map to a file called "algorithm" or "algorithm.h". How this file is actually named, or if the header is even a file in the file system is implementation defined. But the q-char-sequence in the second version does indeed contain a real file name.

@MilfordTea 2015-01-17 13:12:21

@onmyway133 the standard allows for two alternative search mechanisms. If an alternative search mechanism (for include "") is not implemented, include "" functions as include <>. However, this quote from the standards definitely should have a summary -- no one has to waste time figuring out what it implies.

@anatolyg 2015-03-29 19:32:50

"Here's how the C standard can be verbose and not answer your question"

@Jacksonkr 2016-05-04 13:45:17

"The only way to know is to read your implementation's documentation." Or by asking someone on Stack Overflow. I appreciate that you went for the "teaching moment" but I'm afraid that attitude is quickly becoming outdated.

@Maxim Egorushkin 2016-09-17 13:32:31

"both <filename> and "filename" search for implementation-defined places". How is this answer practically useful?

@akhan 2016-10-01 21:25:56

@MaximEgorushkin see Alexander Malakhov's comment for links that describe the implementation for gcc and visual C++. There should be similar documentation for any other commercial compiler. IMO, Alexander's comment should be part of the answer.

@Dave Voyles - MSFT 2016-11-07 19:00:29

People come here to have things explained to them in a manner which they can understand. Simply pointing to cryptic documentation is not helpful. That poor documentation is exactly why so many of us are at this exact question.

@osvein 2017-06-15 12:44:57

@DaveVoyles-MSFT this is the only correct answer, because the question didn't specify which implementation, just "the C and C++ programming languages". How some implementations handle #include has already been pointed out in the comments, which is where they belong because they wouldn't really answer the question.

@Suma 2018-07-08 07:18:57

If the answer is to be of any use, it should mention the intended purpose and common use of those directives, not only quote the standard, which tells how things are defined, but does not tell why. The answer should include the fact <> is used to include standard library headers, while "" is used to include project local includes.

@SteamyThePunk 2018-09-04 17:36:46

The purpose of quoting the standard is to show that there is no answer provided by the standard, as the difference, if any, between these two forms is entirely up to the implementation, Which is why quoting the standard was predicated by suggesting you read your implementation's relevant documentation because OP didn't state what their implementation was. To put it bluntly: There is no standard answer, so you MUST consult your implementation's relevant documentation to find out for your particular case.

@Chayim Friedman 2018-04-12 06:36:36

When you use #include <filename>, the pre-processor looking for the file in directory of C\C++ header files (stdio.h\cstdio, string, vector, etc.). But, when you use #include "filename": first, the pre-processor looking for the file in the current directory, and if it doesn't here - he looking for it in the directory of C\C++ header files.

@IInspectable 2018-10-02 19:31:44

After a perfect answer had been available for years, why submit one, that's just blatantly wrong? Even though common, the #include directive isn't strictly related to files at all.

@Behrooz Karjoo 2019-02-26 20:06:12

@IInspectable please explain why it's not related to files at all.

@Hogstrom 2018-10-03 18:51:45

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.

@Adrian Zhang 2018-03-11 23:06:48

#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 compile.

@Noshiii 2018-08-18 09:24:23

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.

@Jonathan Leffler 2019-07-13 05:26:07

If you decide to answer an older question that has well established and correct answers, adding a new answer late in the day may not get you any credit. If you have some distinctive new information, or you're convinced the other answers are all wrong, by all means add a new answer, but 'yet another answer' giving the same basic information a long time after the question was asked usually won't earn you much credit.

@jigar karangiya 2018-03-28 11:35:39

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.

@Daniel Langr 2018-03-28 11:40:20

Which new information adds this answer to the other ones?

@MobiDev 2012-12-17 07:54:13

  • #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"

@C Johnson 2019-04-23 15:29:42

It has nothing to do with pre-defined header files at all. It has to do with locations to search for.

@quest49 2008-08-22 01:40:27

In practice, the difference is in the location where the preprocessor searches for the included file.

For #include <filename> the preprocessor searches in an implementation dependent manner, normally in search directories pre-designated by the compiler/IDE. This method is normally used to include standard library header files.

For #include "filename" the preprocessor searches first in the same directory as the file containing the directive, and then follows the search path used for the #include <filename> form. This method is normally used to include programmer-defined header files.

A more complete description is available in the GCC documentation on search paths.

@Richard Corden 2008-09-17 13:41:58

The statement: "the preprocessor searches in the same directory..." may be true in practice but the standard states that the named source file is "searched for in an implementation-defined manner". See answer from piCookie.

@Dan Moulding 2009-08-17 16:30:56

While your answer may appear to be "true", because this is how many implementations work by convention, you should take a close look at aib's and piCookie's answers. They both point out (backed by the wording of the C standard) that the real distinction is inclusion of a "header" versus inclusion of a "source file" (and no, this doesn't mean ".h" vs. ".c"). "Source file" in this context can be (and usually is, and almost always should be) a ".h" file. A header does not necessarily need to be a file (a compiler could e.g. include a header that is statically coded, not in a file).

@Gabriel Southern 2012-03-12 21:49:42

"... the preprocessor searches in the same directory as the file being compiled for the file to be included." This statement is not completely correct. I was interested in this question because I was curious what the actual answer is, but I know this is not true because at least with gcc when you specify an additional include path with -I that will search for files specified with #include "filename.h"

@0kcats 2017-11-08 20:46:40

Those who don't like the answer, please, give one practical example, where it is wrong.

@John P 2018-02-23 00:21:33

Sure enough, I recently mixed these syntaxes when including headers from 'the same' library and ended up with redefinition errors. If I understand correctly, #include <...> used the package installed on the system and #include "..." used the nearby repository version. I might have those backwards. Either way, the include guard in the packaged header is prefixed with an underscore. (It could be a convention for packages or maybe a way to deliberately prevent mixing the two, although version qualifiers would make more sense to me.)

@Kamran Poladov 2018-10-04 18:53:49

Why do some windows users #include pch.h file in quotes? It's not somewhat "programmers-defined" file

@mckenzm 2019-01-25 09:21:29

In effect it allows the included content to be "hotfixed" during compilation to "override" the normal include path. It prevents mangling someone else's original (from a github library, say) source. This is very common for Arduino libs and even cores.

@Christy Wald 2017-01-23 13:36:23

#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.

@Suraj Jain 2017-01-14 04:52:16

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.

@Barbara 2011-09-28 20:37:38

#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"

@sp2danny 2014-02-25 10:49:06

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.

@riderBill 2014-10-14 23:51:24

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:

  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.

@Stefan Steiger 2011-02-08 11:45:44

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.

@Keith Thompson 2011-09-07 23:03:28

No, #include "mypath/myfile" is not equivalent to #include "./mypath/myfile". As piCookie's answer says, double quotes tell the compiler to search in an implementation-defined manner -- which includes searching in the places specified for #include <...>. (Actually, it probably is equivalent, but only because, for example, /usr/include/mypath/myfile can be referred to as /usr/include/./mypath/myfile -- at least on Unix-like systems.)

@Stefan Steiger 2014-04-03 09:23:03

@Keith Thompson: That's right, I was thinking of my Linux box. Evidently it could be different. Though in practice, Windows as non-Posix operating system also does interprete / as path separator, and ./ also exists.

@Protongun 2014-04-06 18:07:25

the -L dirpath option then adds dirpath to the defaultincludepaths, as opposed to giving another meaning to the . (as referred to above). This has the expected consequence that both #include "..." and #include <...> search in dirpath

@Carlo Wood 2016-09-27 23:06:00

I think this answer is incorrect, since it implies that headers included with double quotes are always looked for in the current working directory. The search mechanism is way more detailed; this answer is incomplete. I'm not adding this comment to complain or whine, but because the system asks me to add a comment to explain why I voted this answer down.

@Hafiz Shehbaz Ali 2015-04-02 16:50:05

#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.

@skyking 2015-08-18 06:21:43

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).

@Kyle Strand 2016-07-27 17:43:55

This is mostly just the same text as piCookie's answer from seven years earlier.

@skyking 2016-07-28 07:25:10

@KyleStrand That's because the same text is a quote of the relevant section in the standard - that text should be identical. The actual answer is not the same text and is somewhat different - while I also recognize that it will be written in the documentation for the implementation I also note that there's also a traditional way these are interpreted (that most or all compilers I used respects).

@plugwash 2016-09-11 13:59:59

IMO this is the best answer here, because it covers both what the standard says and what most compilers actually do.

@virat 2016-02-17 09:07:12

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.

@Eakan Gopalakrishnan 2013-06-04 15:19:17

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.

@Maxim Egorushkin 2011-02-08 11:45:59

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.

@Maxim Egorushkin 2012-03-27 06:30:01

Not sure why people disagree.

@user3458 2012-03-30 14:07:14

I suspect that's because most people compile only the files in their CWD. If you're in directory foo, and you're compiling foo/unittest/bar.c, and it includes bar.h, then "bar.h" works and <bar.h> does not.

@osvein 2015-07-25 12:16:02

@Maxim people disagree because the behaviour you describe is not standard C.

@Maxim Egorushkin 2016-09-17 13:33:28

@Spookbuster Right, the standard says both <filename> and "filename" search for implementation-defined places.

@Yann Droneaud 2012-07-20 09:29:31

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).

@osgx 2015-03-12 02:34:32

What is exact source of the text? Is it from normative part of IEEE Std 1003.1, 2013?

@Jonathan Leffler 2016-11-10 03:40:37

@osgx: that wording (or something extremely similar) is found in the POSIX specification for c99 — which is the POSIX name for the C compiler. (The POSIX 2008 standard could hardly refer to C11; the 2013 update to POSIX 2008 did not change the C standard that it referred to.)

@user3458 2008-09-03 12:17:00

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.

@juanchopanza 2014-12-28 04:31:32

Could you provide a reference to where in the C standard this -I business is specified?

@user3458 2014-12-28 18:25:46

@juanchopanza done. See also the top answer :)

@juanchopanza 2014-12-28 18:49:15

I see no reference to -I.

@user3458 2014-12-29 14:40:40

That's "implementation-defined" part.

@juanchopanza 2014-12-29 14:42:34

Sigh. I your answer, you make it sound like that is something specified in the language.

@A. Mashreghi 2019-09-18 17:45:45

Great answer, thanks

@srsci 2014-08-27 19:36:49

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.

@aib 2008-09-08 17:43:19

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.

@Dan Moulding 2009-08-17 16:12:17

+1, this is probably the most concise and correct answer here. According to the standard (which piCookie quotes from in his answer), the only real difference is "header" versus "source file". The search mechanism is implementation-defined either way. Using double quotes means that you intend to include a "source file", while angle brackets mean you intend to include a "header" which, as you say, may not be a file at all.

@Nav 2011-01-27 06:38:42

I know I'm asking this a long time after you posted the answer, but @aib, what do you mean by "uniquely refer to a header, which isn't necessarily a file"? Even a header-files are files!

@aib 2011-01-27 09:28:45

See Dan Moulding's comment to quest49's answer; standard headers don't have to be in file form, they can be built-in.

@Maxim Egorushkin 2011-02-08 11:54:18

I've been reading this "standard headers don't have to be in file form" for a decade. Care to provide a real-world example?

@aib 2011-02-08 15:04:31

Don't know of any.

@Martin 2012-09-10 08:06:17

Precompiled header...?

@Dan Moulding 2012-10-12 12:35:07

@Maxim Yegorushkin: I can't think of any existing real-world examples either; however, no complete C11 compiler can exist for MS-DOS unless headers don't have to be files. This is because some of the C11 header names are not compatible with the "8.3" MS-DOS file name limitation.

@gnasher729 2014-02-23 20:55:33

Headers are not necessarily files. If you write #include <stdlib.h>, the header could be directly built into the compiler.

@supercat 2015-08-15 17:57:18

@DanMoulding: The MS-DOS based compilers I've seen would almost invariably interpret #include "thisIsAVeryLongName.and.I.Love.Dots.h" as a request to read a file THISISAV.AND`; one would give a warning that the name in the directive didn't match the file; the rest I've seen would simply ignore that. Would any of the headers required for C11 not work under such a model, e.g. because two distinct names have a shared 8-letter prefix?

@Adrian McCarthy 2017-02-15 23:14:52

@MaximEgorushkin: The VAX/VMS C compiler kept all the C runtime library headers in a single textual library file (similar to a unix archive), and used the string between the < and > as the key to index into the library.

@Wolf 2017-12-11 16:32:53

a header, which isn't necessarily a file -- reminds me of URLs (mostly files in the beginning and these days everything you can think of)

@Denis Ros 2011-10-25 12:35:25

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 )

@Damon 2011-02-08 12:02:32

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.

@Loghorn 2011-02-08 12:59:26

However, using angle brackets or quotes doesn't affect the way the files are included, it is exactly the same: the preprocessor essentally creates a large source file by copy'n'pasting the code from include files to original source file, before giving it to the compiler (preprocessor does other thing, like #define sustitution, #if evaluation, etc. but the #include processing is that easy)

@the_mandrill 2011-02-08 13:10:06

What about conflicts? eg say I have zlib.h in my 'user' search paths, and a different version exists in the system search path, then does #include <zlib.h> include the system version and #include "zlib.h" include my own?

@the_mandrill 2011-02-08 13:10:40

Aha, answered my own question: stackoverflow.com/questions/21593/…

@Kyle Strand 2016-07-27 17:45:45

Thank you for acknowledging that both the standard(s) and typical implementation conventions are both relevant here, rather than simply stating that it's unknowable because it's not specified by the standard.

Related Questions

Sponsored Content

37 Answered Questions

58 Answered Questions

[SOLVED] How do I include a JavaScript file in another JavaScript file?

22 Answered Questions

[SOLVED] What is the "-->" operator in C++?

10 Answered Questions

[SOLVED] What is the difference between g++ and gcc?

  • 2008-10-05 20:25:13
  • Brian R. Bondy
  • 421837 View
  • 802 Score
  • 10 Answer
  • Tags:   c++ gcc g++

24 Answered Questions

[SOLVED] Difference between require, include, require_once and include_once?

10 Answered Questions

15 Answered Questions

8 Answered Questions

[SOLVED] Regular cast vs. static_cast vs. dynamic_cast

  • 2008-08-26 13:20:55
  • Graeme Perrow
  • 667061 View
  • 1650 Score
  • 8 Answer
  • Tags:   c++ pointers casting

2 Answered Questions

Sponsored Content