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
2009-09-02 12:12:51
+19
A:
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
2009-09-02 16:04:18
interesting ... re "headers don't have to be files". Excuse my ignorance, what else can they be?
Rich
2009-09-02 16:51:32
@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 <stddef.h>, 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
2009-09-02 17:49:32
Consider preprocessed headers, where the preprocessor / compiler doesn't have to go through the header source at all...
DevSolar
2009-09-02 18:49:51
+5
A:
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
2009-09-02 12:19:00
To the extent that quotes and angle brackets differ, they do so because the compiler designer felt that they should, and not because of any dictate from the standard.
Nick Bastin
2009-09-02 14:56:55
@Nick: The standard does say that they should differ, but it doesn't say that it's the search algorithm that should differ.
Dan Moulding
2009-09-02 16:05:59
Nick, more or less *all* compiler designers. It does matter, doesn't it? ;-)
Michael Krelin - hacker
2009-09-02 16:15:09
A:
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
2009-09-02 14:54:36
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
2009-09-02 16:08:18
@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
2009-09-03 03:47:12
The substantial difference is that a header doesn't need to reside in the file system...
DevSolar
2009-09-03 04:12:44
The standard may well say that, but it's not always the case.
Chris Huang-Leaver
2009-09-03 07:51:11
@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
2009-09-03 14:12:39
@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
2009-09-03 14:14:18
@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
2009-09-03 14:54:51
+14
A:
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
2009-09-02 16:01:26
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
2009-09-02 16:20:59
@DevSolar: Indeed. But where I come from #including a .c file is considered pure evil. :)
Dan Moulding
2009-09-02 16:22:57
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
2009-09-02 18:46:39
+5
A:
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
#includedirective 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-linesearches 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-linecauses 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-linewith the identical contained sequence (including > characters, if any) from the original directive.
DevSolar
2009-09-02 16:18:33
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
2009-09-03 14:26:18
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
2009-09-03 14:29:42
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
2009-09-04 10:09:27
A:
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
2009-09-02 17:50:04
+1
A:
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.
Pavel Shved
2009-09-02 17:54:49
A:
#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
2009-09-02 17:59:05