Your Visual C++ 6.0 apps will not compile when migrated to Visual Studio 2005 unless you fix them. How do you go about it?

Use this check list to locate incompliant code spots and repair them according the following guidelines.

• Team Work: Developers specializing in different categories can work on the same code simultaneously.
• Coding Standards: It's easier to enforce a uniform coding standard when focusing on one feature at a time.
• Keyword-based Lookup: Each category is typically associated with a specific C++ keyword (e.g., to locate all for-loops, search for the keyword for).
  Code Review and Analysis
  Earlier versions of Visual C++ literally forced you to write non-compliant C++ code. Therefore, it's unlikely that an existing Visual 6.0 app will compile as-is with Visual C++ 8.0 (the C++ compiler of Visual Studio 2005). Therefore, your first step is to review the code and locate potential problems. Before you make any changes to the code, my advice is to review the entire code base and systematically mark all code sections that might be incompatible with Visual Studio 2005. Only then should you make the necessary repairs. It's better to repair incompliant code in several passes, each dealing with a different category of fixes. For example, your first pass may focus on for-loops, the next pass on exception handling, and so on. There are three reasons for splitting the code repairs to separate sessions:
  • Team Work: Developers specializing in different categories can work on the same code simultaneously.
  • Coding Standards: It's easier to enforce a uniform coding standard when focusing on one feature at a time.
  • Keyword-based Lookup: Each category is typically associated with a specific C++ keyword (e.g., to locate all for-loops, search for the keyword for).

Code Fixing
Some of the necessary code fixes are rather straightforward. These include for-loops, pointers to member functions, the deprecated "default to int" rule, and exception handling. Let's see what these all mean.

• for-loops: In pre-standard C++, variables declared in a for-loop were visible from the loop's enclosing scope. This behavior is still maintained in Visual C++ 6.0:

  
  for (int i=0; i<MAX; i++)
  {
    //..do something
  }
  
  int j=i; //allowed in VC++ 6.0
  

  However, in Visual Studio 2005, the scope of i is restricted to the for-loop. If you want to refer to this variable from the enclosing scope, move its declaration outside the for-loop:

  
  int i=0;
  for (; i<MAX; i++)
  {
    //..do something
  }
  int j=i; //OK
  

  Figure 1. Exception Handling: This image shows how to override the default exception handling command line flag.

• Declarations of pointers to members: In pre-standard C++, it was possible to take the address of a member function without using the & operator:

  
  struct S
  {
   void func();
  };
  
  void (S::*pmf)() = S::func; //allowed in VC++ 6.0
  

  In Visual Studio 2005, the & is mandatory:

  
  void (S::*pmf)() = &S::func; //OK
  

  Tip: To locate problematic code, search for the tokens ::* and ::.
• "default to int": Pre-standard C++ (and all C variants predating C99), use the "default to int" rule when declarations of functions and variables do not contain an explicit datatype. This behavior is maintained in Visual C++ 6.0 as the following declarations show:

  
  const x=0; //implicit int
  static num; // implicit int
  myfunc(void *ptr); //implicit return type int
  

  In Visual Studio 2005, you have to specify the datatype explicitly:

  
  const int x=0; 
  static int num; 
  int myfunc(void *ptr);  
  

  Tip: To locate incompliant code of this category, compile your app with Visual Studio 2005 and look for compilation errors about a missing datatype in a declaration.

• Exception Handling: Older versions of Visual C++ happily mixed standard C++ exceptions with the asynchronous Structured Exception Handling (SEH). Consequently, a catch(...) block might catch not just a C++ exception created by a throw statement, but also an asynchronous SEH e.g., access violation. Not only is this behavior incompliant, it makes debugging more difficult. Visual Studio 2005 fixes this loophole. It's now possible to specify whether a catch(...) handler should catch only C++ exceptions by using the default /EHsc flag (this is the recommended option), or maintain the non-standard behavior of Visual C++ 6.0 by using the /EHa flag (see Figure 1).

Author's Note: The fixes shown here don't reflect all of the changes in Visual Studio 2005. For a complete list, consult Visual Studio 2005 homepage. Also, I have focused on core C++ features. Other Visual C++-specific changes such as multithreaded CRTs, deprecated APIs etc., aren't discussed here.

• for-loops: In pre-standard C++, variables declared in a for-loop were visible from the loop's enclosing scope. This behavior is still maintained in Visual C++ 6.0:

  
  for (int i=0; i<MAX; i++)
  {
    //..do something
  }
  
  int j=i; //allowed in VC++ 6.0
  

  However, in Visual Studio 2005, the scope of i is restricted to the for-loop. If you want to refer to this variable from the enclosing scope, move its declaration outside the for-loop:

  
  int i=0;
  for (; i<MAX; i++)
  {
    //..do something
  }
  int j=i; //OK
  

  Figure 1. Exception Handling: This image shows how to override the default exception handling command line flag.

• Declarations of pointers to members: In pre-standard C++, it was possible to take the address of a member function without using the & operator:

  
  struct S
  {
   void func();
  };
  
  void (S::*pmf)() = S::func; //allowed in VC++ 6.0
  

  In Visual Studio 2005, the & is mandatory:

  
  void (S::*pmf)() = &S::func; //OK
  

  Tip: To locate problematic code, search for the tokens ::* and ::.
• "default to int": Pre-standard C++ (and all C variants predating C99), use the "default to int" rule when declarations of functions and variables do not contain an explicit datatype. This behavior is maintained in Visual C++ 6.0 as the following declarations show:

  
  const x=0; //implicit int
  static num; // implicit int
  myfunc(void *ptr); //implicit return type int
  

  In Visual Studio 2005, you have to specify the datatype explicitly:

  
  const int x=0; 
  static int num; 
  int myfunc(void *ptr);  
  

  Tip: To locate incompliant code of this category, compile your app with Visual Studio 2005 and look for compilation errors about a missing datatype in a declaration.

• Exception Handling: Older versions of Visual C++ happily mixed standard C++ exceptions with the asynchronous Structured Exception Handling (SEH). Consequently, a catch(...) block might catch not just a C++ exception created by a throw statement, but also an asynchronous SEH e.g., access violation. Not only is this behavior incompliant, it makes debugging more difficult. Visual Studio 2005 fixes this loophole. It's now possible to specify whether a catch(...) handler should catch only C++ exceptions by using the default /EHsc flag (this is the recommended option), or maintain the non-standard behavior of Visual C++ 6.0 by using the /EHa flag (see Figure 1).

Just in the Nick of Time
Visual Studio 2005 and Visual C++ 6.0 have different Application Binary Interfaces, or ABIs. This means that the same datatype or function may have different binary layouts and mangled names. The different ABIs affect among other things the std::time_t and wchar_t datatypes.

Visual C++ 6.0 treats std::time_t as a 32-bit integer, whereas in Visual Studio 2005 this type is a 64-bit integer. This change might necessitate code updates if your app assumes a 32-bit time_t e.g., hard-coded buffer sizes and format flags (further information on migrating to 64-bit code is available here). Another ABI change affects the representation of the wchar_t type. Up until now, wchar_t has been a typedef synonymous with unsigned short. However, Visual Studio 2005 treats wchar_t as a built-in type. This change might affect the overload resolution of functions:

int _wtolowers(unsigned short *ws);
wchar_t ws[10] = L"Test";
_wtolowers(ws); 

This code compiles with Visual Studio 6.0 but it will break with Visual Studio 2005 because wchar_t * is incompatible with unsigned short *.

All and Sundry
The changes described here affect not just Visual C++ 6.0 code ported to Visual Studio 2005. Rather, they apply to legacy C++ code ported to an ISO compliant C++ compiler in general. The fear from these changes has led many project managers to defer upgrades at all costs. This policy isn't justified, though. Almost without exception, these changes are only for the best.

Danny Kalev is a certified system analyst and software engineer specializing in C++ and the theoretical aspects of formal languages. He is the author of Informit C++ Reference Guide and The ANSI/ISO Professional C++ Programmer's Handbook. He was a member of the C++ standards committee between 1997 and 2000. Danny recently finished his MA in general linguistics summa cum laude. In his spare time he likes to listen to classical music, read Victorian literature, and explore natural languages such as Hittite, Basque, and Irish Gaelic. Additional interests include archeology and geology. He also gives lectures about programming languages and applied linguistics at academic institutes.


引自：http://www.devx.com/cplus/10MinuteSolution/28908/0/page/1


-------------------------------------------------------------------------------------------------------------------

VC6==>VS2005的一些問題

我接收到一個任務，是把公司的一個產(chǎn)品從vc6遷移到vs2005，結果發(fā)現(xiàn)了很多的warning和error

warning 主要是使用了strcpy,strcat這樣的函數(shù)
這些在2005中都是unsafe_api.
在vs2005都推薦使用strcpy_s,strcat_s.
我想微軟這么做固然跟C++ standard有偏差
但是這些函數(shù)的使用確實造成了微軟產(chǎn)品經(jīng)常有的漏洞
微軟深受這些函數(shù)的危害阿
所以在vs2005這些都是warning

error的類型主要是以下幾種,多半和STL有關

1.include 帶.h的舊式頭文件，比如 #include <iostream.h>改為include <iostream>

2.vc6的string iterator的 char *,而vs2005中卻不是
strcpy(s.begin(), str);是不能compile的，應改為strcpy((char *) s.c_str(),str);

3.函數(shù)返回類型不支持缺省是int
missing type specifier - int assumed. Note: C++ does not support default-int
<Code>
    extern IsWindowsNT();

<Fix>
    extern int IsWindowsNT();