Difference Between #Include ≪Filename≫ and #Include "Filename"

Difference between using #includefilename and #includefilename.h in C++

C++ only include-files not found in the C standard never used filename.h . Since the very first C++ Standard came out (1998) they have used filename for their own headers.

Files inherited by the C Standard became cfilename instead of filename.h. The C files inherited used like filename.h are deprecated, but still part of the C++ standard.

The difference is that names not defined as macros in C are found within namespace std:: in cfilename in C++, while names in filename.h are within the global namespace scope. So you will find ::size_t in stddef.h, and std::size_t in cstddef. Both are Standard C++, but use of ::size_t is deprecated (See Annex D of the C++ Standard).

Now those were the difference.

Why would you use `filename.h` ?

Compatibility with C compilers
Compatibility with very old C++ compilers

Why should you use `cfilename` ?

Names are within namespace std:: . No name-clashes anymore.
New C++ features (e.g. overloaded math functions for float, long)
C Compatibility Headers (filename.h) could disappear in future.

Difference between #include filename & #include filename [duplicate]

In general, the <> version should look only in "system directories", while the "" should look in the "local directories" first, and then the system directories.

What that actually means is implementation dependent. In most cases "" will look in the current directory first, but in some implementations it will look in the directory of the source (.c) file first (and some compilers have a switch for that). Also, behavior is different w.r.t. the "set of system directories" to search if "local directory search" fails (the same as for <> or not).

What are the differences between #include filename and #inlude filename specific to LLVM/Clang?

I couldn't find anything in the documentation that specifies the expected behavior in each case, so I was curious and decided to look at the code in here. Might be wrong to assume this is how it will always behave, but without the documentation, I guess the source code is the next best thing.

Searching through the code I found that the #include pragma is processed here in the HandlePragmaDependency method (line 453), where it determines if the include isAngled or not (line 468) and then uses that value as a parameter to the LookupFile() method (line 477).

This method is defined in the HeaderSearch.cpp (line 498) and the documentation comment for it states that:

[...] isAngled indicates whether the file reference is for system #include's
or not (i.e. using <> instead of ""). [...]

Later in that method the value for isAngled is used in three places (line 547, 596 and 673) each of which have the following comments.

  // Unless disabled, check to see if the file is in the #includer's
  // directory.  This cannot be based on CurDir, because each includer could be
  // a #include of a subdirectory (#include "foo/bar.h") and a subsequent
  // include of "baz.h" should resolve to "whatever/foo/baz.h".
  // This search is not done for <> headers.
  if (!Includers.empty() && !isAngled && !NoCurDirSearch) {

  ...

  // If this is a system #include, ignore the user #include locs.
  unsigned i = isAngled ? AngledDirIdx : 0;

  ...

  // If we are including a file with a quoted include "foo.h" from inside
  // a header in a framework that is currently being built, and we couldn't
  // resolve "foo.h" any other way, change the include to <Foo/foo.h>, where
  // "Foo" is the name of the framework in which the including header was found.
  if (!Includers.empty() && !isAngled &&
      Filename.find('/') == StringRef::npos) {

Hope it helps.

C++ - #include filename

While the exact details are implementation-dependent, there are a few common practices. In most common compilers, using the quotes #include "filename.h" searches the current directory by default. Using angle brackets #include <filename.h> searches system-defined library directories. What it is saying is that if the current directory doesn't have the file you need, it will search the system directories instead.

Note that some compilers may be different, and your compiler itself may have options to change these directories. There is also the possibility that system headers don't actually exist, but that #include <foo.h> is directly recognized by the compiler to enable certain built-in definitions.