Вы находитесь на странице: 1из 2

Hi !

Can any one explain whats the difference in the following usage?

1.
#include <iostream>

and

2.
#include <iostream.h>

Either can be used while coding, but if we use 1., then all keywords

have to be explicitly qualified by their namespace. Ex std::cout,std::cin, etc.

but when using 2. the explicit qualification is not required.

Which usage is better? As I have been using 2. only and have recentlycome to know
about form 1.

Differences in iostream Implementation

The main difference between the Standard C++ library and previous run-time
libraries is in the iostream library. Details of the iostream implementation
have changed, and it may be necessary to rewrite parts of your code that use
iostream if you want to link with the Standard C++ library.

You will have to remove any old iostream headers (fstream.h, iomanip.h,
ios.h, iostream.h, istream.h, ostream.h, streamb.h, and strstrea.h) you have
included in your code and add one or more of the new Standard C++ iostream
headers (fstream, iomanip, ios, iosfwd, iostream, istream, ostream, sstream,
streambuf, and strstream, all without the .h extension).
If your old application is very iostream intensive, you may choose not to
link with the new Standard C++ library. In this case, leave the old iostream
headers in your code and the old iostream library will automatically be
linked. However, you cannot include any of the new Standard C++ library
headers. You cannot mix calls to the old iostream library and the new
Standard C++ library.

The following list describes behavior in the new Standard C++ iostream
library that differs from behavior in the old iostream library.
In the new Standard C++ iostream library:
open functions do not take a third parameter (the protection parameter).

You cannot create streams from file handles.

You cannot open ofstream objects with the ios::out flag alone. The ios::out
flag must be combined with another ios enumerator in a logical OR; for
example, with ios::in or ios::app.

ios::good no longer returns a nonzero value after reaching the end-of-file


because the eofbit state is set.

ios::setf( IFlags ) should not be used with a flag value of ios::dec,


ios::oct, or ios::hex unless you know that none of the base flags are
currently set. The formatted input/output functions and operators assume
that only one base is set. Instead, use 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 instead of the previous value.

istream::get( char& rch ) does not assign to rch if there is an error.

istream::get( char* pch, int nCount, char delim ) is different in three


ways:
When nothing is read, failbit is set.

An eos is always stored after characters extracted (this happens regardless


of the outcome).

A value of -1 for nCount is an error.


istream::seekg with an invalid parameter does not set failbit.

The return type streampos is a class with overloaded operators. In functions


that return a streampos value (such as istream::tellg, ostream::tellp,
strstreambuf::seekoff, and strstreambuf::seekpos), you should cast the
return value to the type required: streamoff, fpos_t, or mbstate_t.

The first function parameter (falloc) in strstreambuf::strstreambuf( falloc,


ffree ) takes a size_t argument, not a long.
In addition to the above changes, the following functions, constants, and
enumerators that are elements of the old iostream library are not elements
of the new iostream library:
attach member function of filebuf, fstream ifstream, and ofstream

fd member function 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 (use rdbuf()->pubsetbuf() for the same behavior)

Вам также может понравиться