<iostream> vs. <iostream.h> vs. “iostream.h”

Question

When including a header file in C++, what's the difference between...

1) including the .h versus not including the .h when wrapping it in < > signs?

#include <iostream> vs. #include <iostream.h>

2) wrapping the header name in double quotes versus wrapping it in < > signs?

#include <iostream.h> vs. #include "iostream.h"

Thanks in advance!

Answer 1

In short:

iostream.h is deprecated - it is the original Stroustrup version, and iostream is the version from the standards committee. Generally compilers point them both to the same thing, but some older compilers won't have the older one. In some odd cases they will both exist and be different (to support legacy code) and you then must be specific.

"" versus <> simply means check the local directories for the header before going to the library (in most compilers).

-Adam

Answer 2

Here is a decent link article.

To summarize, the reason given:

The version of the iostream library that the Standards Committee produced was quite a bit different from the CFront implementation. {snip}

To ease transition, the C++ Standards Committee declared that code including the standard C++ headers would use include directives that lack an extension. This allowed compiler vendors to ship the old style C++ library headers with the .h extension and the new style headers without.

An advantage of not using the .h version:

There are several reasons why new code should be written using the extensionless version of the header files instead of the .h forms. The first is the unpredictability of such code when compiled on modern compilers. As previously mentioned, the result of using the .h headers is implementation specific. And as time goes by, the chance that a given compiler will have the old style library available decreases.

Answer 3

As the person on the standards committee (X3J16) who proposed leaving off the .h, my original intent was to settle the debate over .h, .H, .hpp, .hxx, or .h++ file extensions; or a desire by some that there be no implication in the standard that this was the name of a file on disk in order to allow an IDE to pull pre-compiled header information out of someplace internal like a resource file or even the guts of the compiler.

While Unix considered the filename to be a single string and did not actually recognize the concept of an extension, DEC operating systems had a tradition of separating the name from the extension, and supplying the "default extension" if it was omitted in particular contexts. That's where I got the idea from of leaving it up to the implementation to use whatever extension the implementation wanted to use, and it allowed the implementation to not even have this a file on disk. (I was DEC's rep. on the committee at the time.)

Differentiating between the standard and the pre-standard headers was an added benefit.

Answer 4

The standard way (and the only one guaranteed to work) is <iostream>. On gcc, <iostream.h> (which might need to be included as <backward/iostream.h>) pulls the relevant declarations to the global namespace (so you do not need the std:: namespace prefix).

"iostream.h" would try first from the directory with your source code, since "" is meant for headers from your project. <> should always be used for system headers, and "" for your own headers.

Answer 5

Typically <> is used for system or standard library files whereas "" is used for project files. I would not be surprised if your compiler searches locally and when it cannot find it it defaults to the standard library version.

As for the .h, I don't think that it actually matters if you use C. In C++, I remember vaguely that there was a newer version and an older version and that without the h it was supposed to be the new version, but I'm not even sure the old version still exists.

Answer 6

These are really two different questions.

• The difference between the .h and extensionless headers with the same name is historical. The ones with the .h extension are from the original C++ standard which did not have some modern features such as namespaces and templates. It was simpler for the new standard to put that same functionality in new header files to be able to use these new features and keep the old (.h) files for backward compatibility of legacy code.

• The difference between the #include <...> and #include "..." format is the order in which the compiler looks for files. This is generally implementation dependent, but the idea is that the <> format looks in system include directories first, while "" looks in the same directory as the source file that #included it first.

Answer 7

The simple answer to the first answer is that iostream.h doesn't exist, at least in the GCC implementation. If you're on *nix, type

% locate iostream.h
/usr/include/c++/3.4.3/backward/iostream.h

and

% locate iostream
/usr/include/c++/3.4.3/iostream
/usr/include/c++/3.4.3/backward/iostream.h

As Zee's article says, iostream.h is for backward compatibility.

Answer 8

Regarding the names of the standard C++ header files, in the early days (first 2 years) of X3J16, we faced an argument over what the extension should be on the standard C++ header files. In use at the time by various vendors (and influenced by constraints that some operating systems placed on file names) I believe there were .h, .H, .h++, .hpp, .HXX, and possibly others. In a library group meeting I suggested that we leave the extension off, and leave it up to the implementation to supply a default file extension of its choosing if there was none in the include line, or use the name as a key in a database of pre-compiled header files if desired. [While Unix-like systems treat the filename and 'extension' as a single string, I was representing DEC on the committee, and many DEC operating systems stored the extension in the directory as a separate field from the name. So DEC operating systems had a strong tradition of applying a default extension based on what program was accessing the file for what purpose. Telling an assembler 'X,Y=Z' might result in reading input file Z.MAC (macro) and writing output files X.OBJ and Y.LST.] Anyway, it avoided a long, no-win debate, so the group went along with it, and Andy Koenig presented the group's conclusions on this (among others) to the entire committee which accepted it. I find it somewhat amusing that implementations missed the whole point that they could apply a default extension of their choice (which I would think would be useful to editors and other tools) and just left the extension off of the file name.