Iostream and iostream. h)

The C ++ standard class library has been revised twice, with two standards c92 and c99, both of which are currently used in parallel. h contains c92, not. H is the header file of c99. For common users, there is no difference between the two. The difference lies in the specific implementation of internal functions. The old c ++ header file is officially opposed to use, but the old c header file is not (to maintain compatibility with C ). It is said that the old iostream library was removed from Visual C ++. NET 2003. In fact, the compiler manufacturer will not stop providing support for the customer's existing software, so in the foreseeable future, the old c ++ header file will be arrogant for a while. If you can understand the use of the string header file, the other will be used:
<String. h> is the old C/C ++ header file, which corresponds to a string processing function based on char;
<String> the C ++ header file of STD is packaged, corresponding to the new strng class;
<Cstring> is the STD Version corresponding to the old c header file.
 
If the compiler supports both <iostream> and <iostream. h>, use # include <iostream> to obtain the elements of the iostream library placed under the namespace STD. If you use # include <iostream. h>, the same elements are placed in the global space. Retrieving elements in a global space results in name conflicts. The original intention of designing a namespace is to avoid such name conflicts.

Just like the software downloaded by Xunlei, first determine the size of the downloaded file from the server. At the beginning, the file is saved and all files are filled with 0,
Download data from multiple threads and write data directly to the file. Rewrite the 0 value of the file slice that the thread is responsible for downloading,
This involves file sharing and write operations.

 

When the problem occurs:
Vc7.1 <fstream> does not support keywords such as filebuf: sh_read. I do not know how to implement non-exclusive read and write operations on files using file streams in vc7?

And:
Iostream. h In vc6.0 <fstream. h>
Filebuf: sh_read
Filebuf: sh_write
Filebuf: sh_note
Filebuf: sh_openprot

Whether you are using vc6 or vc7 ide
When standard input/output and file streams are used:
Include <iostream>
Include <fstream>
Using namespace STD;

There are two usage methods:
A:
Include <iostream. h>
Include <fstream. h>

B:
Include <iostream>
Include <fstream>

A is a standard usage, and B is an old-fashioned usage.
If <iostream> is used, you must introduce the namespace, that is, "using namespace STD ;".
If <iostream. h> is used, the namespace is not introduced. Otherwise, a compilation error is prompted.
The namespace cannot be found. The routine is as follows:
// Scenario 1: Use the <iostream> and namespace
# 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

// Scenario 2: Use <iostream. h> without introducing a namespace
# 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 3: <iostream. h> is used to introduce the namespace. An error occurs during compilation.
# Include <iostream. h>
Using namespace STD;
Int main ()
{
Cout <"<iostream> need to use namespace STD! /N ";
Return 0;
}
Compilation error message:
Error c2871: 'std ': does not exist or is not a namespace

The old iostream library is removed from Visual C ++. NET 2003.
The major difference between the standard C ++ Library and the previous Runtime Library is the iostream library. The implementation details of iostream have been changed. to link to the Standard C ++ library, it may be necessary to rewrite the iostream part of the code.
You must remove any old iostream header files (fstream. h. iomanip. h. IOS. h. iostream. h. istream. h. ostream. h. streamb. H and strstrea. h ), add one or more standard C ++ iostream header files (<fstream>, <iomanip>, <IOS>, <iosfwd>, <iostream>, <istream>, <ostream>, <sstream>, <streambuf>, and <strstream>, none of the header files. h extension ).
The following table describes the behavior of the new standard C ++ iostream library different from that of the old iostream library.
In the new Standard C ++ iostream Library:
The open function does not use the third parameter (Protection parameter ).
You cannot create a stream from the 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 use the C ++ library header.
The ofstream object cannot be opened with the IOS: Out flag. The IOS: Out sign must be combined with another IOS enumeration number in the logic or. For example, it must be combined with IOS: In or IOS: app.
Because the eofbit status is set, no non-zero value is returned for iOS: good after the file is reached.
Unless you know that no base flag is set, IOS: SETF (_ iflags) should not be used with the flag values for iOS: Dec, IOS: Oct, or IOS: Hex. Formatted input/output functions and operators are assumed to have only one base. Use ios_base instead. For example, SETF (ios_base: Oct, ios_base: basefield) clears all base information and sets the base to octal.
IOS: unsetf returns void instead of the previous value.
If an error occurs, istream: Get (char & _ RCH) is not allocated to RCH.
Istream: Get (char * _ PCH, int _ ncount, char _ delim) has three differences:
Set failbit when no content is read.
The extracted characters are always stored with an EOS (irrelevant to the result ).
When the value is-1, _ ncount is an error.
Failbit is not set for istream: seekg with invalid parameters.
Streampos is a class with overload 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 required type: streamoff, fpos_t, or mbstate_t.
The first function parameter in strstreambuf: strstreambuf (_ falloc, _ Ffree) uses the size_t parameter instead of the long parameter.
Except for the above changes, the following functions, constants, and enumerations used as elements of the old iostream library are not elements of the new iostream Library:
Attach Member functions of 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 (the same behavior uses rdbuf-> pubsetbuf)

 

Stl faq has some suggestions on the usage of the standard library, and there are also articles discussed in this regard in the software development magazine. Unfortunately, such a good magazine has also been closed (maybe the above knowledge is too advanced for Chinese programmers. what others have said is strange. How can I understand it ).

What's the difference between <XXX> and <XXX. h> headers

The headers in ISO Standard C ++ don't have. h suffix. this is something the Standards Committee changed from former practice. the details are different between headers that existed in C and those that are specific to C ++.

The C ++ standard library is guaranteed to have 18 standard headers from the C language. these headers come in 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 since t the <CXXX> versions provide their declarations in 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 so that existing C code cocould continue to be compiled in C ++. however the <XXX. h> versions are deprecated, meaning they are standard now but might not be part of the standard in future revisions. (see clause D.5 of the iso c ++ standard .)

The C ++ standard library is also guaranteed to have 32 additional standard headers that have no direct counterparts in C, such as <iostream>, <string>, and <New>. you may see things like # include <iostream. h> and so on in old code, and some compiler vendors offer. h versions for that reason. but be careful:. h versions, if available, may differ from the standard versions. and if you compile some units of a program with, for example, <iostream> and others with <iostream. h>, the program may not work.

For new projects, use only the <XXX> headers, not the <XXX. h> headers.

When modifying or extending existing code that uses the old header names, you shoshould probably follow the practice in that Code unless there's some important reason to switch to the standard headers (such as a facility available in Standard <iostream> that was not available in the vendor's <iostream. h> ). if you need to standardize existing code, make sure to change all c ++ headers in all program units including external libraries that get linked in to the final executable.

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

The standard library extends the original library. For example, the new library <string> also supports wide Character Set Operations, so I think that most compilers now support Standard C ++, all programs should use the standard header file import method!

For the use of namespace STD, the FAQ in C ++ is as follows:

Shocould I use using namespace STD in my code?

Probably not.

People don't like typing STD: over and over, and they discover that using namespace STD lets the compiler see any std name, even if unqualified. the fly in that ointment is that it lets the compiler see any std name, even the ones you didn't think about. in other words, it can create name conflicts and ambiguities.

For example, suppose your code is counting things and you 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 cocould cause ambiguities.

Look, the whole point of namespaces is to prevent namespace collisions between two independently developed piles of code. the using-Directive (that's the technical name for using namespace XYZ) implements tively dumps one namespace into another, which can subvert that goal. the using-directive exists for legacy C ++ code and to handle the transition to namespaces, but you probably shouldn't use it on a regular basis, at least not in your new C ++ code.

If you really want to avoid typing STD:, then you can either use something else called a using-declaration, or get over it 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 cocould insert Using STD: cout into your code. this is unlikely to cause confusion or ambiguity because the names you bring in are explicit.
 

Just type STD: (the UN-solution ):
# Include <vector>
# Include <iostream>
 
Void F (const STD: vector <double> & V)
{
Using STD: cout; // define a using-declaration that lets you 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.
Either way is fine. Just remember that you are part of a team, so make sure you use an approach
That is consistent with the rest of your organization.