Difference Between Iostream and Iostream.H

Difference between iostream and iostream.h

iostream.h is deprecated by those compilers that provide it, iostream is part of the C++ standard.

To clarify explicitly there is no mention of iostream.h at all in the current C++ standard (INCITS ISO IEC 14882 2003).

Edit: As @Jerry mentioned, not only does the current standard not mention it, but no standard for C++ mentions it.

iostream vs. iostream.h vs. iostream.h

In short:

iostream.h is deprecated—it is the original Stroustrup version. 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).

Is this a difference between iostream.h and iostream

No "system" header is required to be a file. Inclusion using <> is specified thusly:

C++11 16.2 [cpp.include]/2: 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.

So the declarations from headers known to the implementation (which might or might not include current and/or obsolete standard library headers) can be made available without loading and preprocessing a text file, if the implementor deems that to be a good idea.

Including with "" will first search for a file (in implementation-defined places), and fall back to <> if that fails.

What is the difference between including iostream and including iostream.h?

iostream.h is not part of the standard C++ library whereas iostream is. Names in iostream.h are not in the std namespace, whereas those in iostream are. By issuing the directive using namespace std after including iostream, all names defined there (and in any other standard library includes) are brought into the global namespace. That is usually not a good thing, but it does provide some level of equivalence between the standard and non- or pre-standard versions.

As far as claiming that they are "the same" as each other, this is unlikely. iostream adheres to the standard, and will have evolved w.r.t. iostream.h. This is particularly true if you consider the C++11 standard.

What is the différence between #include iostream.h and #include iostream?

Before C++ was even standardised, the I/O library was developed as <iostream.h>. However, that header has never been a standard C++ header. Some older compilers continued to distribute the <iostream> header also as <iostream.h>. Use <iostream> because it is guaranteed by the standard to exist.

It's worth noting that the only standard headers that end with .h are the C standard library headers. All C++ standard library headers do not end with .h.

Difference between iostream and iostream (quotes) in #include?

When you use < >, the compiler only looks in the system-designated directory/directories (e.g., whatever you've set in the include environment variable) for the header.

When you use " ", the compiler looks in the local directory first, and if that fails, re-searches just like you'd used < >. Technically, (i.e., according to the standard) that doesn't have to be the "local" directory, but that's how it works in essentially every compiler of which I'm aware).

In case you care, the official wording from the standard is actually kind of vague (§16.2/2-3):

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.

What The Difference between stdio.h and iostream?

stdio.h is the header file in the C standard library. It is used for input/output

iostream is the input output class in C++

So if you're using C++ just use #include <iostream>

What is the relationship between iostream and namespace std?

All of the standard library definitions are inside the namespace std. That is they are not defined at global scope, so in order to use them you need to qualify them in one of the following way:

• std::cout
• using namespace std
• using std::cout

For instance lets take this:

// declarations
int global_variable;

namespace n {
int variable2;
}

global_variable can be access as it is:

int x;
x = global_variable;

But variable2 is not part of the global space, but part of the namespace n.

int x;
x = variable2; // error variable2 identifier not found.

So you have to use the fully qualified name:

int x;
x = n::variable2;

As a shortcut you can write:

using namespace n;
int x;
x = variable2; // variable2 is searched in current namespace
               // and in all namespaces brought in with using namespace
               // Found ONLY in namespace n -> OK

or

using n::variable2; // this makes any unqualified reference to `variable2`
                    // to be resolved to `n::variable2`
int x;
x = variable2;

As for the header files, iostream.h was used by many compilers before there was a standard. When the committee tried to standardize they decided to make the C++ headers extensionless in order not to break compatibility with existing code.

---

Related Topics