About the C language include angle brackets and double quotation marks dialog

A: #include "..." What is the difference between #include <...>?

B: He meow, such a simple question. Angle brackets are found in the system directory, double quotation marks are first found in the current directory, can not find the system directory.

A: That's very vague. So I ask you, the current directory has a file called Hdr.h,
There is also a sub-directory under the current directory sub with two files Hdr.h and 1.c in the sub,
1.c in # include "Hdr.h",
So in the current directory compiled sub/1.c, which hdr.h should it contain?

bash-3.2$ Tree |--Sub |   |--1.c | '--hdr.h '--hdr.h bash-3.2$ cat sub/1.c #include "hdr.h" bash-3.2$ gcc-c sub/1.c

B: It should contain the hdr.h outside, because it works in the current directory of GCC, and the subdirectory's hdr.h is not in the current directory, should not be searched.

A: Wrong, it contains the Sub/hdr.h!

B: Ah!... Oh... The double quotation marks are first found in the directory where the source file of the include is located (that is, the 1.c directory sub is looking for), not the current working directory of the compiler to find, I originally understood wrong.

A: Yes, the include double quotes for GCC and msvc are found first in the directory where the source files for the include are used.

How is the B:C99 standard stipulated? is the source file current directory or the compiler working directory?

A: In fact, C99 standard does not specify # include "..." To find out which directory to start with, just say, depending on the implementation, you can design a C compiler include double quotes when you design the way you look (if you can't find the degenerate to # include <...>). But the de facto industry standard is "double quote precedence from the directory where the source files using include".

B: I get it.

A: Then I ask you again, #include <...> so-called "from the System directory", then "system directory" exactly what, how to look at it?

B: Compile-time-i-specified directory chant.

A: If you do not specify the-I parameter, is the system directory list empty?

B: Of course not, there is a default.

A: What do you think of the default?

B: I don't know about this. What do you think?

A: In the case of GCC, run echo at the command line | GCC-E-V-

bash-3.2$ Echo | GCC-E-V-* * * #include "..." search starts here: #include <...> search starts here:/usr/lib/gcc/i686-pc  -linux-gnu/4.8.2/include/usr/local/include/usr/lib/gcc/i686-pc-linux-gnu/4.8.2/include-fixed/usr/include End of Search list.

B: So I'm assigning gcc-i. Join the list as a search path or convert the current directory to an absolute path?

A: That's a good question! In fact, I do not know, or we can try.

bash-3.2$ Echo |   GCC-E-v-i.-* * * #include "..." search starts here: #include <...> search starts here:. /usr/lib/gcc/i686-pc-linux-gnu/4.8.2/include/usr/local/include/usr/lib/gcc/i686-pc-linux-gnu/4.8.2/ Include-fixed/usr/include End of the search list.

B: It does not turn into an absolute path, it is a point.

A: Well, then the problem comes, under the circumstances (note: 1.c content modified to #include

bash-3.2$ Tree |--Sub |   |--1.c | '--hdr.h '--hdr.h bash-3.2$ cat sub/1.c #include 
B: I guess I'll use the hdr.h of the subdirectory.
A: I guess I'll use the outer hdr.h,
Write a 1 in Hdr.h,
Write a 2 in Sub/hdr.h,
Then Gcc-e-I. sub/1.c.
You see the result is 1, I guess right!
B: Well, it appears that the search path list is based on the compiler working path.
About the C language include angle brackets and double quotation marks dialog