What is the difference between #include <filename> and #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.

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.

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.

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.

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

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

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.

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