15

Possible Duplicate:
what is the difference between #include <filename> and #include “filename”

Is there a fundamental difference between the two #include syntax, apart from the way the path the compiler will search for?

I have the feeling that Intel's compiler does not give exactly the same output.

Community
  • 1
  • 1
fulmicoton
  • 15,502
  • 9
  • 54
  • 74

8 Answers8

24

The fundamental difference is in which paths are searched.

You're supposed to use the angle bracket form for "system" includes, and regular quotes for project-local includes.

unwind
  • 391,730
  • 64
  • 469
  • 606
  • 5
    In practice this may be true but the real difference, as per the C language standard, is whether the compiler should search for a *header* or a *file*. (Hint: headers don't have to be files, though they almost always are). – Dan Moulding Sep 02 '09 at 16:04
  • interesting ... re "headers don't have to be files". Excuse my ignorance, what else can they be? – Rich Sep 02 '09 at 16:51
  • 2
    @Rich: For instance, they could be compiler/preprocessor built-ins. Rather than searching for a file on the file system, the preprocessor could just insert code that is hard-coded into itself when standard headers are included. Or it could query a database for the header's contents, download the header from the internet... you get the idea. But if instead of asking for , you ask for "stddef.h", then the compiler *should* first search for a file named stddef.h, even if it has a stddef.h built-in to it (or available via some other means). – Dan Moulding Sep 02 '09 at 17:49
  • Consider preprocessed headers, where the preprocessor / compiler doesn't have to go through the header source at all... – DevSolar Sep 02 '09 at 18:49
23

The C language standard says that <> is to be used for "headers" and "" is to be used for "source files". Now, don't get all up in arms about the "source files" thing. When the standard says "source files", it doesn't mean what you think. The term "source files" as used in the standard encompasses what we colloquially call "header files" (in addition to what we commonly call "source files").

When the standard talks about "headers", it isn't specifically talking about files at all. The standard does not require headers to exist as files. They could be built-in to the compiler for all the standard cares.

So the real difference between <> and "" is that <> is used for headers and "" is used for files. If you know that the source you'll be including is a file then you should use "".

In practice, compilers use different search algorithms for <> versus "". This is allowed by the standard as the search algorithm to be used for either one is implementation defined. But this is not the real difference as expressed by the standard.

Dan Moulding
  • 211,373
  • 23
  • 97
  • 98
  • I have on occasion hacked a source to actually include a .c file. It wasn't nice, I would not recommend it, but it is indeed possible. *What* you #include doesn't really matter, as long as the outcome is valid C source. ;-) – DevSolar Sep 02 '09 at 16:20
  • @DevSolar: Indeed. But where I come from #including a .c file is considered pure evil. :) – Dan Moulding Sep 02 '09 at 16:22
  • Here too. But I felt like it. ;-) (Actually it was what you'd call a "high speed course" in C for Unix, where the instructor and us two pupils went through 460 pages of book in five days. I needed the same functions over and over again one day, but the breaks were never long enough to make it into a proper two-C-and-one-H-plus-Makefile setup that it should have been, so I simply included that other C file. Instructor was quite... agitated when he saw what I was doing. ;-) – DevSolar Sep 02 '09 at 18:46
  • Relevant: implementation in [g++](http://gcc.gnu.org/onlinedocs/cpp/Include-Syntax.html) and in [visual c++](http://msdn.microsoft.com/en-us/library/36k2cdd4(v=vs.110).aspx) – Alexander Malakhov Oct 10 '12 at 03:41
7

Dan Moulding got it right; unwind, hacker, and Nick Bastin got it wrong. Sorry.

#include <...>

is for headers, which need not even be files in the filesystem, but could e.g. be internal to the compiler.

#include "..."

is for files, and only if no such file can be found, does it default back to #include <...>.

How and where these headers and files are looked for, and whether < > should be used for system files and " " for project files, which is indeed a common convention, is completely up to the compiler and the project.

The C Standard (ISO/IEC 9899:1999) says (emphasis mine):

6.10.2 Source file inclusion

Constraints

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

Semantics

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.

DevSolar
  • 67,862
  • 21
  • 134
  • 209
  • And if you can point to the place in the standard where "source file" is defined to be different from "header", then you can stay on your high horse. The only real mention of even an attempt to define "source file" is in a footnote that says (in 5.1.1.2 (5)): "Source files, ... need not necessarily be stored as files, nor need there be any one-to-one correspondence between these entities and any external representation." – Nick Bastin Sep 03 '09 at 14:26
  • Further, in the Rationale for the C99 Standard - "The primary reason that explicit rules were not included in the Standard is the infeasibility of describing a portable file system structure." (6.10.2-5) The only difference between "headers" and "source files" at all is that the Standard reserves some header file names - "The Standard specifies a set of include file names which must map onto distinct host file names. In the absence of such a requirement, it would be impossible to write portable programs using included files." (6.10.2-15) – Nick Bastin Sep 03 '09 at 14:29
  • I didn't want to "mount the high horse". I was always under the impression that the standard considered headers and source files to be two not necessarily identical things, and argued from that position. Searching the doc, I find 5.1.1.1 (1), 6.4.7 (2), 6.10.2, footnote 156) to 7.1.2, and 7.1.2 (3) to support the notion that headers and source files to be two different things. – DevSolar Sep 04 '09 at 10:09
6

Quotes instruct to search first in current directory, then in system directories (either path hardcoded in compiler/preprocessor or specified with -I). By using angle brackets you opt out of searching the current directory first.

Compiler output definitely does not depend on the quotes because it's handled at the preprocessing stage. Except for the case when due to the altered search behavior different files are being included.

Michael Krelin - hacker
  • 138,757
  • 24
  • 193
  • 173
3

For gcc compiler there is difference between <> and "" headers. If <> header is included from the directory that's supplied as -isystem to preprocessor, then warnings are not emitted for the header included. With -Werror this makes a huge difference in certain cases.

Intel compiler also does have -isystem directive, so it may be applicable to icc as well.

Let alone the difference in lookup directories that's too obvious to note.

P Shved
  • 96,026
  • 17
  • 121
  • 165
1

#include <somefile.h>

will check the system include paths (including any additional path's added for a project).

#include "somefile.h"

will check the applications working folder. (i.e. same folder as the source file that has the #include statement in it).

Robert French
  • 686
  • 4
  • 12
0

Warning: this is pure speculation. I do not have enough experience with the Intel compiler to know if it works this way, nor am I aware of any compiler that does.

If a compiler implements pre-compiled headers, it might use those for one form of include but not the other. If the pre-compiled header gets out of sync with the actual header, you would get different results depending on which was included.

Mark Ransom
  • 299,747
  • 42
  • 398
  • 622
-1

There is no technical difference in general, and everything anyone tells you about it just local style, probably influenced by past compilers - many modern compilers implement the initial search in exactly the same way (often other common behaviors are available via command line option). The standard leaves the behavior in the hands of the implementer, with no particular rationale for supporting both syntaxes.

As per section 6.10.2 of the ISO C99 standard, the search paths for <> and "" are both implementation-defined. The ONLY difference between them in the eyes of the standard is that using "" will fall back on <> if it cannot be resolved. (Don't be tripped up by the standard seeming to make a distinction between "header" and "source file" - there isn't a difference actually defined by the standard other than the fact that some names are reserved - "stdio.h", etc.)

Nick Bastin
  • 30,415
  • 7
  • 59
  • 78
  • If you read the standard a little more closely, you'll see that <> applies to *headers* while "" applies to *source files*. Note that "source file" as used by the standard doesn't mean the same thing it typically connotes in colloquial conversation. – Dan Moulding Sep 02 '09 at 16:08
  • @Dan Moulding: And that would actually matter if the standard made a substantial distinction between source files and headers, but in fact it does not. – Nick Bastin Sep 03 '09 at 03:47
  • The substantial difference is that a header doesn't need to reside in the file system... – DevSolar Sep 03 '09 at 04:12
  • The standard may well say that, but it's not always the case. – Chris Huang-Leaver Sep 03 '09 at 07:51
  • @DevSolar: "source files" don't need to reside in the filesystem either - the standard doesn't ever use such a word or define it. In fact the very reason these things are implementation defined is that the standard doesn't presume how "files" are stored in your operating system (otherwise record-oriented filesystems in OSes like VMS wouldn't be able to support a C compiler) – Nick Bastin Sep 03 '09 at 14:12
  • @Chris Huang-Leaver: Of course it's always the case - implementation defined means that there's no non-compliant implementation. The only true answer to this question in the specific is if someone surveys all modern compilers and determines their behaviour. – Nick Bastin Sep 03 '09 at 14:14
  • @DevSolar: From the relevant section of the standard (5.1.1.2(5)) - "Source files, ... need not necessarily be stored as files, nor need there be any one-to-one correspondence between these entities and any external representation." – Nick Bastin Sep 03 '09 at 14:54
  • Footnote 159 to 7.1.2(1): "A header is not necessarily a source file, nor are the < and > delimited sequences in header names necessarily valid source file names." Do you still claim the standard doesn't define a difference? – Dan Moulding Dec 13 '11 at 12:53