difference of #include <> and ""

[bill]

Forget the exact definition of difference between,

#include <foo.h>

and

#include "bar.h"

Normally foo.h is a standard header file, so it's path is not defined
in compiler option, but I am curious how compiler find it.

 

[tinybyte]

Normally foo.h is a standard header file, so it's path is not defined
in compiler option, but I am curious how compiler find it.

The fundamental difference is that when using "" the preprocessor begin
searching from the directory where it found the file enclosed between "".
Using <>, preprocessor begins from standard locations, such as
/usr/include.

 

[Kevin Goodsell]

The fundamental difference is that when using "" the preprocessor begin
searching from the directory where it found the file enclosed between "".
Using <>, preprocessor begins from standard locations, such as
/usr/include.

I /think/ that the standard doesn't actually specify anything like that.
I'll have to check to see what it does specify. Also, your first
sentence doesn't seem to make much sense.

-Kevin

 

[Joona I Palaste]

I /think/ that the standard doesn't actually specify anything like that.
I'll have to check to see what it does specify. Also, your first
sentence doesn't seem to make much sense.

Generally, <> is for headers required by the standard or otherwise
provided along with the implementation, and "" is for headers you wrote
yourself or got from a third party.

 

[Kevin Goodsell]

Here's the relevant section from n869:

6.10.2 Source file inclusion

Constraints

[#1] A #include directive shall identify a header or source
file that can be processed by the implementation.

Semantics

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


To summarize, #include "" directives cause the implementation to search
in an implementation-defined manner for the source file indicated. If
this fails, it tries again using the search method that it normally uses
for #include <> directives (which is also implementation-defined).
Another (sort of) important difference is that #include <> directives
need not specify an actual source file - the implementation defines how
it determines what text is used to replace the directive.

The remainder of section 6.10.2 follows.


[#4] 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.134) 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.

[#5] The implementation shall provide unique mappings for
sequences consisting of one or more letters or digits (as
defined in 5.2.1) followed by a period (.) and a single
letter. The first character shall be a letter. The
implementation may ignore the distinctions of alphabetical
case and restrict the mapping to eight significant
characters before the period.

[#6] A #include preprocessing directive may appear in a
source file that has been read because of a #include
directive in another file, up to an implementation-defined
nesting limit (see 5.2.4.1).

[#7] EXAMPLE 1 The most common uses of #include
preprocessing directives are as in the following:

#include <stdio.h>
#include "myprog.h"

[#8] EXAMPLE 2 This illustrates macro-replaced #include
directives:

#if VERSION == 1
#define INCFILE "vers1.h"
#elif VERSION == 2
#define INCFILE "vers2.h" // and so on
#else
#define INCFILE "versN.h"
#endif
#include INCFILE

Forward references: macro replacement (6.10.3).

Footnotes:

134 Note that adjacent string literals are not concatenated
into a single string literal (see the translation phases
in 5.1.1.2); thus, an expansion that results in two
string literals is an invalid directive.

-Kevin

 

[E. Robert Tisdale]

Generally, <> is for headers required by the standard
or otherwise provided along with the implementation
and "" is for headers you wrote yourself or got from a third party.

No.
*Traditionally* (meaning the UNIX tradition), angle brackets < >
are for headers considered part of the [operating] system
(including the C compiler and third party headers installed
[by the systems administrator] for use by multiple users):

/usr/include/linux/console.h
/usr/include/math.h
/usr/include/X11/X.h

for example
and double quotes "" "" are for headers that are part
of a programmers application program:

> cat main.c
#include "main.h"

int main(int argc, char* argv[]) {
// . . .
return 0;
}

If you are implementing a library which may be installed
in a system directory such as:

/usr/include/

by the system administrator for the target platform,
you should expect programmers who use your library to write:

#include <library.h>

 

[tinybyte]

I /think/ that the standard doesn't actually specify anything like that.
I'll have to check to see what it does specify. Also, your first
sentence doesn't seem to make much sense.

Yes, I've messed up the things quite a bit I'm sorry.
I've read that on the K&R, and maybe got it wrong.

Will not speak anymore.
Bye

 

[Kevin Goodsell]

Yes, I've messed up the things quite a bit I'm sorry.
I've read that on the K&R, and maybe got it wrong.

Will not speak anymore.
Bye

Don't take it personally when people correct you on this group.
Everybody gets corrected. A large part of the usefulness of this group
comes from the fact that messages are heavily peer-reviewed so that
errors get weeded out.

-Kevin

 

[tinybyte]

Don't take it personally when people correct you on this group.
Everybody gets corrected. A large part of the usefulness of this group
comes from the fact that messages are heavily peer-reviewed so that
errors get weeded out.

I didn't take it personally, but the next time I will take more time to
doublecheck my posts (I was in a real hurry when I posted the followup
to this one). I'm sorry if I gave the impression of being upset by your
followup: I am not.

I fully agree with you about the usefulness of the peer-reviews.
You'll see many more posts from me, and I hope to see as many corrections

Bye
Daniele "tinybyte"

 

[Joona I Palaste]

I didn't take it personally, but the next time I will take more time to
doublecheck my posts (I was in a real hurry when I posted the followup
to this one). I'm sorry if I gave the impression of being upset by your
followup: I am not.

I fully agree with you about the usefulness of the peer-reviews.
You'll see many more posts from me, and I hope to see as many corrections

That's good to know. We're C programmers, not the Inquisition. If you
think you're right, go ahead and post. If you're wrong, you'll be told
so, but that doesn't mean you're a bad or unworthy person. If you're
right, then all the better.

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"And according to Occam's Toothbrush, we only need to optimise the most frequent
instructions."
- Teemu Kerola