Header file extension removed from c++ ( Error: No such file iostream.h)

 error c1083

<iostream.h> or <iostream>?

A frequent piece of advice is often given to new C++ programmers is to use <iostream> instead of <iostream.h> or <fstream> instead of <fstream.h>. This is often given with only the explanation that the .h forms are deprecated without explaining what the difference is and why, in fact, using the extensionless version is superior.

Although the <iostream.h> library was deprecated for several years, many C++ users still use it in new code instead of using the newer, standard compliant <iostream> library. What are the differences between the two? First, the .h notation of standard header files was deprecated more than 5 years ago. Using deprecated features in new code is never a good idea. In terms of functionality, <iostream> contains a set of templatized I/O classes which support both narrow and wide characters. By contrast, <iostream.h> classes are confined to char exclusively. Third, the C++ standard specification of iostream's interface was changed in many subtle aspects. Consequently, the interfaces and implementation of <iostream> differ from <iostream.h>. Finally, <iostream> components are declared in namespace std whereas <iostream.h> components are declared in the global scope. Because of these substantial differences, you cannot mix the two libraries in one program. As a rule, use <iostream> in new code and stick to <iostream.h> in legacy code that is incompatible with the new <iostream> library. 

The Advantages of New Over Old

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.

Even given a compiler that has the CFront iostream library available, there are concrete benefits to using the standard version. For one thing, the standard version has an interface that is exception aware. This includes both defining exceptions that the iostream library may throw, but also reducing the number of ways that the iostream library may be interfaced in exception unsafe ways. For example, elimination of two stage construction of iostream objects reduces the possibility of leaking resources.

The new style iostreams also integrate better with the rest of the Standard C++ Library. The best example of this is using istreambuf_iterators to load an entire file into a container.

Also, the standard C++ library has better localization support. This includes the use of locales with stream objects to handle things such as determining if a "." or a "," is used as a decimal seperator. It also includes wide character support to handle a larger range of local characters.

Migration Hints

A large amount of sample code and tutorials are still available that uses the CFront iostream library. This is often old code that simply was never updated to take advantage of the standard. Given the task of modifying code that uses the old style iostream library to the standard version, the most common problems are as follows:

1. The standard iostream library lives in the std namespace. This can be fixed by either the application of an using declaration or prefixing the relevant identifiers with std::.
2. The nocreate flag doesn't exist in the standard library version of the iostream library. However, a std::ifstream object will not open a file if it doesn't exist. So one way to bypass this restriction is to first attempt to open the file with a std::ifstream object. If the std::ifstream object fails to open the file, abort the operation. If it succeeds, close the file, and reopen the file with the desired file class. Similar techniques can be done with a std::fstream or std::filebuf object in place of the std::ifstream object with the right combination of flags.
3. The noreplace flag doesn't exist in the standard library version of the iostream library either. To get the functionality of the noreplace flag you need to reverse the logic of the nocreate flag: open the file first with a std::ifstream (or std::filebuf or std::fstream object with the appropriate flags) and if it suceeds than abort the operation. Otherwise reopn the file with the desired end file class.
4. Manual forward declarations of iostream objects may not compile depending on the compiler. The easiest solution is to replace such forward declarations with the inclusion of the iosfwd header.
5. The CFront istream and ostsream classes had protected default constructors. Code extending the CFront iostream library to create custom stream classes would derived from istream or ostream and call the default constructor, followed by a call to init(). The standard library replaces this two stage construction method with a single argument constructor that accepts a streambuf object. Also the standard iostream objects will no longer take ownership of the streambuf assigned in the constructor. The consequence is that the derived class will need to manage the lifetime of the streambuf.

 you can see the following examples of Hello world

#include <iostream>

int main(int, char **) {
  std::cout << "Hello World!" << std::endl;

  return 0;
}

OR

 #include <iostream>

int main(int, char **) {
  using namespace std;

  cout << "Hello World!" << endl;

  return 0;
}

OR

#include <iostream>

int main(int, char **) {
  using std::cout;
  using std::endl;

  cout << "Hello World!" << endl;

  return 0;
} 

 reference: http://www.devx.com, http://members.gamedev.net