Visual Studio 2008 has several advantages over Visual C++ 6.0 including a more standards compliant C++ compiler, support for new targets like X64 and mobile, improved STL implementations, and an updated IDE interface. However, some disadvantages of moving to VS2008 are that the IDE is slower, IntelliSense has performance issues, and deployment is more complicated due to side-by-side assemblies.

1. Advantages of Visual Studio 2008 over Visual C++ 6.0
•Much more standards compliant C++ compiler, with better template handling
•Support for X64/Mobile/XBOX targets
•Improved STL implementations
•Support for C++0X TR1(smart pointers, regular expressions,etc)
•Secure C runtime library
•Improved code navigation
•Improved debugger; possibility to run remote debug sessions
•Better compiler optimizations
•Many bug fixes
•Faster builds on multi-core/multi-CPU systems
•Improved IDE user interface, with many nice features
•Improved macro support in the IDE; DTE allows access to more IDE methods and variables
•Updated MFC library(in VS2008 Service Pack 1)
Disadvantages of moving to Visual Studio 2008
•The IDE is a lot slower than VS6
•Intellisense still has performance issues(replacing it with VisualAssistX can help)
•Side by side assemblies make app deployment much more problematic
•The local(offline) MSDN library is extremely slow
•As mentioned theres no profiler in the professional version
1.Deprecated functions — To eliminate warning messages, define several preprocessor symbols in
order to continue using certain runtime functions that have been deprecated. For example, if code
calls functions such as strcpy(), sprintf(), etc., these functions are now deprecated, and the compiler
will generate warnings like this:
warning C4996: 'strcpy': This function or variable may be
unsafe. Consider using strcpy_s instead. To disable
deprecation, use _CRT_SECURE_NO_WARNINGS
These are the symbols need to be defined to eliminate the warnings without making any
code changes:
_USE_32BIT_TIME_T
_CRT_SECURE_NO_WARNINGS
_CRT_NONSTDC_NO_WARNINGS
These are to be added in the
Project Properties->Configuration properties->C/C++ -> PreProcessor ->Preprocessor
Definitions
2. Precompiled header files work differently — In Visual C++ 6 and Visual Studio 2003, there
was an “Auto generate” option for precompiled headers. That option does not exist
anymore. If user wants precompiled headers, you need to explicitly specify a .h file that will
serve as the stopping point for generating the precompiled header file. Then, you need to set
each .cpp file to either “Use Precompiled Header”, or “Create Precompiled Header”.
Typically, you set a single .cpp file (e.g., stdafx.cpp) to “Create” and everything else to
“Use”. The easiest way to do this is to set “Use” at the project level so it propagates down,

2. then override a single .cpp file (e.g., stdafx.cpp) to “Create”. NOTE: If you have any .cpp
files that do not include the .h file identified as the stopping point for your precompiled
header, you must set these .cpp files to “Don’t use precompiled header”; otherwise, the
compiler will generate an error when compiling these .cpp files (“End of file found looking
for precompiled header”)
3. Debugging issue with static libraries — When building static .lib files, there is a potential
issue if you want to use the debugger with code that resides in the .lib file. Specifically, if a
static .lib file is built with debug info and precompiled headers, you’ll be able to step into
code in the .lib file, but you will not be able to inspect any data structures that are private to
the .lib (i.e., data structures that are not visible in .h files included in the application that
linked with the .lib file). To resolve this, include the /Yl linker switch (that’s capital Y lower-
case L) when building the .lib file. You need to supply a symbol name with this switch, but
the name can be anything. Here’s the actual switch I used in all of my projects:
/YlFakeSymbol. Add this to Project Properties -> Linker -> Command Line -> Additional
options.
4. Recommendation for static .lib files — When building a debug version of a static .lib file,
consider using the older “C7 Compatible” debug format rather the default “Program
Database” format. The debug format setting is available in Project Properties -> C/C++ ->
General -> Debug Information Format. The advantage to using the C7 format is that the
debug information is embedded directly in the .lib file (instead of a separate .pdb file), so
there’s only one file to keep track of. When using the .lib file in other projects, it eliminates
the potential for getting debug info out of sync (e.g., if you update the .lib file but forget to
update the .pdb file).
5. Manifest file — By default, Visual Studio 2008 generates a manifest file and embeds the
manifest into the .exe when building. If you want to add/modify settings to the auto-
generated file, the easiest way to do that is to create a .manifest file with you custom
settings, then include the file in your project just like any other source file. When you build,
the settings in your custom file will be automatically merged with the auto-generated
settings. Note that for this to work, your file must have a .manifest extension.
6. The old iostream library was removed beginning in Visual C++ .NET 2003.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>).