Compilation issues for Migration from VC6 to VC9

I am porting a legacy C++ system from VC6 to VC9.

The application (<APP A>) statically links to an internal application <APP B> ( developed in house but by a separate team). A local copy of header files from <APP B> are included in CPP files and compiled in <APP A>.

Currently we are not planning to migrate <APP B> to VC9. Though both <APP A> and <APP B> will use the separate CRTs but no conflict expected.

The issue we are facing is that include files from ( local copy in ) are not getting compiled with VC9.

fatal error C1083: Cannot open include file: 'iostream.h': No such file or directory

Possible solutions: If I make the changes in local co开发者_StackOverflow社区py of <APP A> and compile with VC9 then I am not sure if it can cause some problem during runtime.

Is there any other way in which I can ask VC9 to compile the <APP A> files with <iostream.h> instead of <iostream> ?

---

Sorry, but you're in a load of problems.

First the basics: <iostream.h> is an older Microsoft header, that was used to define e.g. ::cout. <iostream> is the Standard header, and defines e.g. std::cout. You can use both of those, but this header should not be included in APP.H. <iostream> does not define types that you'd use in declarations. Presumably you're relying on an artifact of the VC6 implementation, namely that <iostream.h> pulled in <istream.h> and <ostream.h>. You might want to switch to <iosfwd> instead, which is intended to be used in headers.

The bigger problem is however your assumption that you can just link "APP A" and APP B" together, even though they are compiled with VC6 and VC9. This is true if and only if they share an extern "C" API. C++ name mangling is (intentionally) different between them. And since you mentioned <iostream.h> instead of <stdio.h>, I'm going to assume that your common is really C++.

---

There is a great book by Michael Feathers http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052, about this type of project.

The short answer is if you have tests, make the required changes and refactorings and rerun your tests. For your example, I would use a preprocessor directive to pick the right include based on compiler version, and then fix any broken tests.

Without tests you're in a bit more trouble, you'll have either write them or pray you don't break anything

---

I doubt that this compiler error will be the only problem. Updating the compiler almost always introduces a small number of problems. Its best to solve these conflicts and to test the result seriously. I dont thing that some "Workaround" will make less trouble as the compiler is different anyway.

The only solution to solve such problems when using different compilers in parallel is conditional compilation such as:

#if _MSC_VER >= 1200 
   // Code for VC 6.0 or higher goes here
#endif

Be aware that the number _MSC_VER differs from that of the Version of Visual Studio. For Visual Studio 2010, i.e _MSC_VER is defined as 1600.