9

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

Why doesn't the compiler complain when I write the following:

#include "stdio.h"

Shouldn't it be 

#include <stdio.h>

instead, because stdio.h is actually stored in a library folder and not in the folder of the translation unit? Why does it work anyway?

Community
  • 1
  • 1
gexicide
  • 38,535
  • 21
  • 92
  • 152
  • 1
    `"..."` looks locally *first*, and then elsewhere. – BoBTFish Dec 03 '12 at 13:40
  • 1
    no, it should really be `#inlcude ` – 111111 Dec 03 '12 at 13:40
  • 1
    http://stackoverflow.com/questions/21593/what-is-the-difference-between-include-filename-and-include-filename – BoBTFish Dec 03 '12 at 13:41
  • @111111, it's not the point of the question, is it? –  Dec 03 '12 at 13:46
  • @aleguna which is why it is a comment – 111111 Dec 03 '12 at 13:47
  • @111111 That's debatable. If I want a C header, then specifying it as a C header would seem the most reasonable solution. (And if I'm not concerned about C, then it should be ``, so that I can use something that isn't completely broken.) – James Kanze Dec 03 '12 at 13:51
  • @JamesKanze Whilst on the whole I agree, there are reasons to use `stdio` in C++ (for one `std::printf` is thread safe). Further more given a question like this I am pretty sure that the OP just didn't know that `cstdio` was preferred. – 111111 Dec 04 '12 at 11:20

3 Answers3

10

The difference between "" and <> isn't much. Both search for the header in implementation-defined places1, 2. The difference is that if that search fails for "", the search happens as if it was using <>. (§16.2)

Basically, this means that if <> finds a header with a certain name, "" does not fail to find a header with the same name3.

1 These implementation-defined places do not have to be the same for both forms.

2 There is no requirement that one of these search library folders and the other search the folder of the TU. The compiler is allowed to search the whole filesystem and even google for it if it wants.

3 This does not mean that they always find the same header, though.

R. Martinho Fernandes
  • 228,013
  • 71
  • 433
  • 510
  • There is a requirement, though, that if `#include "xxx"` fails, the compiler reprocess it as if it had been `#include `. – James Kanze Dec 03 '12 at 13:46
  • @James That's what I intended the third sentence to mean. Do you think I should rephrase it, or did you miss that? – R. Martinho Fernandes Dec 03 '12 at 13:47
  • +1 for googling source files :-) – Angew is no longer proud of SO Dec 03 '12 at 13:58
  • I think the significant reason for the "places" being so loosely specified is that header "files" don't have to be actual files, let alone in an actual filesystem. You could write a conforming C++ implementation over some kind of version control or whatnot, just as long as it can figure out what bytes the nominal "file" contains. And of course in practice both locations depend on command-line options. – Steve Jessop Dec 03 '12 at 14:16
  • @SteveJessop, yeah wouldn't it be nice to be able to `include` different revisions of the same file from mercurial, or whatever vcs.. %) `#include "MyClass.h.99fdadcf54"` –  Dec 03 '12 at 14:28
  • @aleguna: hmm, personally I'll stick with checkout followed by a compile. I suspect that what the committee had in mind was more like an IDE that would compile your source without it necessarily ever hitting a filesystem. No doubt more than one person has written a C compiler in emacs lisp in the past :-) – Steve Jessop Dec 03 '12 at 14:29
  • @SteveJessop another possible thing that would be awesome would be for standard library headers to be magically implemented within the compiler, in a way that they don't leak anything; strictly only the symbols required by the standard to be defined in the header would show up: no including and getting std::size_t. You cannot do that in plain C++, but you can do it easily with magic non-C++-file headers that are actually just bits of preset compiler state. Sadly everyone took the easy way out and jump dumped C++ files somewhere in the file system. – R. Martinho Fernandes Dec 03 '12 at 15:10
  • @R.MartinhoFernandes: that would indeed be very useful, especially when writing portable code. I'm not sure you actually require not-written-in-C++ standard headers for that, would it be sufficient to have a pragma that just lists the symbols the header is supposed to define, plus some compiler magic to enable "don't leak symbols other than this until the end of the file" mode? It's nice to be able to inspect headers to see exactly what overloads, macros and template definitions are there. I wouldn't necessarily enjoy learning a new language just to read standard headers. – Steve Jessop Dec 03 '12 at 15:52
  • @Steve oh, guess that could work too, yes. – R. Martinho Fernandes Dec 03 '12 at 16:00
1

This is because of how the include syntax is defined.

#include <cstdio> means that the compiler should include the standard library cstdio

#include "cstdio" means the compiler should try to find the file "cstdio", looking primarily in the current directory and using the location of the standard libraries as a fallback.

Agentlien
  • 4,996
  • 1
  • 16
  • 27
  • 2
    Whether or not either `#include <>` or `#include ""` look in the current directory first or at all is entirely implementation defined. – CB Bailey Dec 03 '12 at 13:43
1

"" versus <> only changes the order of lookup.

so with

#include "stdio.h"

precompiler will start lookup from the directory of translation unit, and then move to predefined "include" directories

Whereas

#include <stdio.h>

Is other way around

  • @CharlesBailey But in practice, it is generally accepted that the "..." include should first look in the directory which contains the file with the include. (On the other hand, I don't think any compiler will look in the current directory for an include, unless you pass it `-I.` or the file it is reading is in the current directory.) – James Kanze Dec 03 '12 at 13:48
  • @CharlesBailey, where did I say anything about **current** directory? –  Dec 03 '12 at 13:50
  • @aleguna: Sorry, for "current directory" read "directory containing the initial source file for the translation unit being compiled". I was being lazy. – CB Bailey Dec 03 '12 at 13:51
  • Whether or not either `#include <>` or `#include ""` look in the directory containing the initial source file for the translation unit being compiled or the directory containing the source file containing the include directive being interpreted, either first or at all is entirely implementation defined. – CB Bailey Dec 03 '12 at 13:53
  • @CharlesBailey, theory and references to standard are all good and well. But it practice all mainstream [pre]compilers work as I described. And I'm sure the question was about real world behaviour, not about what's in the standard –  Dec 03 '12 at 13:55
  • Whether `"xxx.h"` and `"xxx.hpp"` refer to the same or different files is also implementation defined. In practice, there are generally established practices, and we expect compilers to follow them. – James Kanze Dec 03 '12 at 13:55
  • @aleguna: Yes, which is what prompted me to comment. You said "will" without a qualification such as "in general" so I commented to clarify. – CB Bailey Dec 03 '12 at 13:57
  • In actual practice, `#include "stdio.h"` doesn't always look first in the directory of the TU. It might well look first in the directory of the file that contains the `#include` directive like James mentioned (I think that's the more common). Which it does affects how indirect includes behave, and it can cause some commotion if your source needs to be portable between implementations that behave differently. So Charles's comments are very relevant to real world behavior. It's not just some hypothetical implementation that behaves differently from what this answer says. – Steve Jessop Dec 03 '12 at 14:23