The difference between iostream and iostream.h detailed analysis _c language

The standard class library for C + + has been revised two times, there are two standard C92 and C99, these two libraries are now in parallel use, with. h contains the c92, without. h is C99 header file, for ordinary users, the two are not different, the difference is in the specific implementation of internal functions. The old C + + header file was explicitly opposed by the official, but the old header file did not (to maintain compatibility with C). It is said that the old iostream library has been removed from Visual C + +. NET 2003. In fact, the compiler manufacturer will not stop supporting the customer's existing software, so in the foreseeable future, the old C + + header file will be arrogant for some time. If you can understand the use of the string header file, extrapolate, the other will be almost used:

<string.h> is the old C/s + + header file, corresponding to the string processing function based on char*;
<string> is an STD-packaged C + + header file, corresponding to the new STRNG class;
<cstring> is the STD version of the old C header file.

If the compiler supports both < iostream > and < iostream.h, it uses #include < iostream to get the elements of the iostream library that are placed under the STD of the name space; if you use # Include < iostream.h to get the same element that is placed in global space. Acquiring elements in the global space causes the name conflict, and the original purpose of the design namespace is to avoid the occurrence of this name conflict.

Imagine lightning download software, the first from the server to determine the size of the download file, the original is to save the file, all filled 0, more than one thread download data directly written to the file, the thread is responsible for downloading the piece of the file 0 to rewrite, which involves file sharing write operation

When a problem arises:
Vc7.1<fstream> has not supported filebuf::sh_read and other keywords, I do not know under the VC7 to use file flow to the file for inclusive read and write operations how to achieve?

and
The iostream.h <fstream.h> in vc6.0
Filebuf::sh_read
Filebuf::sh_write
Filebuf::sh_note
Filebuf::sh_openprot

Whether you're using the VC6 or the VC7 IDE,
When you use both standard input and output and file streams:
Include<iostream>
Include<fstream>
using namespace Std;

There are two ways to use it:
A:
Include<iostream.h>
Include<fstream.h>

B:
Include<iostream>
Include<fstream>

A is a standard usage, B is an old-fashioned usage.
If <iostream> is used, be sure to introduce a namespace, that is, "using namespace std;".
If the <iostream.h> is used, then the namespace is not introduced, which causes compilation errors, prompting the namespace to be found, and the routines are as follows:

Case one: Use <iostream> and namespaces
#include <iostream>
using namespace Std;
int main ()
{
cout<< "<iostream> need to use namespace std!/n";
return 0;
}
Output:
<iostream> need to use namespace std!
Press any key to continue

Case two: Use <iostream.h>, do not introduce namespaces
#include <iostream.h>
using namespace Std;
int main ()
{
cout<< "<iostream> need to use namespace std!/n";
return 0;
}
Output:
<iostream> need to use namespace std!
Press any key to continue

Case three: Use <iostream.h>, introduce namespaces, compile error
#include <iostream.h>
using namespace Std;
int main ()
{
cout<< "<iostream> need to use namespace std!/n";
return 0;
}
Compile error message:
Error C2871: ' STD ': does not exist or be not a namespace

Starting with Visual C + +. NET 2003, remove the old iostream library.
The main difference between the standard C + + library and the previous Run-time library is the iostream library. The specifics of the iostream implementation have changed, and if you want to link to a standard C + + library, it may be necessary to rewrite the parts of your code that use iostream.
You must remove any old iostream header files contained in your code (fstream.h, Iomanip.h, Ios.h, iostream.h, istream.h, Ostream.h, Streamb.h, and STRSTREA.H) and adds one or more new standard C + + iostream header files (<fstream>, <iomanip>, <ios>, <iosfwd>, <iostream >, <istream>, <ostream>, <sstream>, <streambuf>, and <strstream> All header files do not have. h extension).
The following table describes the behavior of the new standard C + + iostream library as distinct from the old iostream library.

In the new standard C + + iostream library:
The open function does not take the third argument (the protection parameter).
Cannot create stream from file handle.
Except for a few exceptions, all the names in the new standard C + + library are in the STD namespace. For more information, see Using C + + library headers.
The Ofstream object cannot be opened with the IOS::OUT flag alone. The IOS::OUT flag must be combined in a logical OR and another iOS enumerator, for example, a combination of ios::in or Ios::app.
Because the Eofbit state is set, the Ios::good no longer returns a value other than 0 after reaching the end of the file.
Unless you know that the base flag is not currently set, IOS::SETF (_iflags) should not be used with iOS::d ec, ios::oct, or Ios::hex flag values. formatted input/Output functions and operators assume that only one base is set. Switch to Ios_base. For example, SETF (IOS_BASE::OCT, Ios_base::basefield) clears all base information and sets the base to octal.
IOS::UNSETF returns void rather than the previous value.
In the event of an error, Istream::get (char& _rch) is not assigned to Rch.
Istream::get (char* _pch, int _ncount, char _delim) has three different points:
Set Failbit when no content is read.
An EOS is always stored after the extracted character (regardless of the result).
Value of-1 o'clock _ncount is an error.
ISTREAM::SEEKG with invalid parameters do not set failbit.
The return type Streampos is a class with overloaded operators. In functions that return streampos values (such as ISTREAM::TELLG, OSTREAM::TELLP, Strstreambuf::seekoff, and Strstreambuf::seekpos), The return value should be converted to the desired type: Streamoff, fpos_t, or mbstate_t.
The first function argument in Strstreambuf::strstreambuf (_falloc, _ffree) takes a size_t parameter instead of a long.

In addition to the above changes, the following functions, constants, and enumerators as old iostream library elements are not elements of a new iostream library:
Attach member functions for FILEBUF, FStream Ifstream and Ofstream
FD member functions of FILEBUF, FStream Ifstream and Ofstream
Filebuf::openprot
Filebuf::setmode
Ios::bitalloc
Ios::nocreate
Ios::noreplace
Ios::sync_with_stdio
Streambuf::out_waiting
Streambuf::setbuf (same behavior using rdbuf-> pubsetbuf)

There are some suggestions on the usage of the standard library on the STL FAQ, in the "Software Research and Development" magazine also has this discussion article, unfortunately, such a good magazine has ceased (perhaps the above knowledge of Chinese programmers too much ahead, people say, strange, I see how to understand).

What ' s The difference between <xxx> and <xxx.h> headers

The headers in ISO Standard C + + don t have a. h suffix. This is something the standards committee changed from former practice. The details are different between headers that existed in C and those this are to C + +.

The C + + standard library is guaranteed to have standard headers from the C language. These headers come into two standard flavors, <cxxx> and <xxx.h> (where xxx is the basename of the header, such As Stdio, stdlib, etc). These two flavors are identical except the <cxxx> versions provide their declarations into the Std namespace only, and The<xxx.h> versions make them available both in Std namespace and in the global namespace. The Committee did it this way, existing C code could continue to is compiled in C + +. However the <xxx.h> versions are deprecated, meaning they are standard now but might not being part of the standard in Future revisions. (clause D.5 of the ISO C + + standard.)

The C + + standard library is also guaranteed to have additional standard headers this have no direct counterparts in C, such as <iostream>, <string>, and <new> You may be things like #include <iostream.h>, and some compiler vendors an offer. h Versions for that reason. But is careful:the. h versions, if available, may differ from the standard versions. And if you are compile some units of a, for example, <iostream> and others with <iostream.h>, the pro Gram May is not work.

For new projects with the<xxx> headers, not the<xxx.h> headers.

When modifying or extending existing code this uses the old header names, you should probably follow the practice in Code unless there ' s some important reason to switch to the standard headers (such as a facility available in Standard<i Ostream> that is not available in the vendor ' s <iostream.h>). If you are need to standardize existing code, make sure to change all C + + headers in all program units including external Libr Aries that linked the final executable.

All of this affects the standard headers. You ' re free to name your own headers anything [27.9].

The standard library extends the original library, such as the new library <string> also supports wide character set operations, so I think that in the case where most compilers already support standard C + +, all programs should use the standard header file import Method!

For the use of the namespace namespace std, the answer to the C + + FAQ is this

Should I use using the namespace STD in I code?

Probably not.

People don ' t like typing std:: Over and over, and they discover that using namespace Std lets the compiler to the any Std nam E, even if unqualified. The fly in that ointment are that it lets the compiler to any STD name, even the ones you didn ' t. In the other words, it can create name conflicts and ambiguities.

For example, suppose your The code is counting things and your happen to use a variable or function named count. But The STD library also uses the name count (it's one of the STD algorithms), which could and cause.

Look at the whole point of the namespaces are to prevent namespace collisions between two independently developed of code. The using-directive (that's the technical name for using namespace XYZ) effectively dumps one namespace into another, whic H can subvert that goal. The using-directive exists for legacy C + + code and to ease the transition to namespaces, but your probably shouldn ' t use it On a regular basis, at least not in your new C + + code.

If you are really want to avoid typing std::, then your can either use something else called a using-declaration, or get over I T and just type std:: (The Un-solution):

Use a using-declaration, which brings in specific, selected names. For example, to allow your code to use the name cout without a std:: qualifier, you could insert using std::cout into your Code. This is unlikely to cause confusion or ambiguity because the names for you bring in are.

Copy code code as follows:

Just type std:: (The Un-solution):
#include <vector>
#include <iostream>

void f (const std::vector<double>& v)
{
Using Std::cout;//←a using-declaration that lets to use cout without qualification

cout << "Values:";
for (Std::vector<double>::const_iterator p = v.begin (); P!= v.end (); ++p)
cout << ' << *p;
cout << ' n ';
}

Get over it and

#include <vector>
#include <iostream>

void f (const std::vector<double>& v)
{
Std::cout << "Values:";
for (Std::vector<double>::const_iterator p = v.begin (); P!= v.end (); ++p)
Std::cout << ' << *p;
Std::cout << ' n ';
}

I personally find it's faster to type std:: "than to decide, for each distinct STD name, whether
Or not to include a using-declaration and if so, to find the best scope and add it there. But
Either way is fine. Just Remember that you are part's a team and so make sure your use a approach
That's consistent with the rest of your organization.