从VC6.0平台级到VS2008平台

从VC6.0平台级到VS2008平台

最近在在把一些程序从VC6迁移到VS2008，由此而关注到一些这方面的知识，找了一些资料，根据自己遇到的一些情况，结合在一起，整理出来这篇文章，希望对以后有这方面工作的人多一些参考，如果大家还有可很享的可以跟贴。。。。

1、关于 #define WINVER

提到这个问题是因为，这里涉及到Winodws版本的定义。关于版本定义的关键无外乎为程序头文件中对于#define WINVER 和 #define _WIN32_WINNT 的使用，具体为：

#define WINVER 0xXXXX

#define _WIN32_WINNT 0xXXXX

该定义一般用于标示程序对运行环境的要求，另外在某些头文件中也有这样的宏定义。如果版本匹配的话就会在编译的时候将这些内容编译，否则就不编译。

定义正确的Windows版本，不仅关系到程序的正确编译，同时也关系到程序的正确运行；在升级的过程中，我就碰到了程序编译正确但运行出错的问题。

版本的定义关系到被编译到程序中的内容，这里主要是指系统提供的功能代码。Windows各个版本的功能虽然大差不差，但特定于某个系统功能还是存在的，于是关系到这些功能的API代码也就有所不一样。当我们在程序中定义了错误的系统版本，被编译进程序的内容便可能包含当前系统不支持的代码片段，这样的程序即使可能正确编译通过，但在运行的时候，由于在当前系统中找不到相应的内容资源，从而发生错误。这一点熟悉动态链接库(DLL)的人都很清楚，其实该问题就是和系统动态链接库有关。
考虑到我迁移程序的时候，是直接利用VS2008将VC6程序转化的方式，然后按VS2008新建项目的StdAfx.h文件内容更新了原来的StdAfx.h头文件，并添加了VS2008项目才有的targerver.h头文件。(工程转换时，没有targerver.h为我们生成，默认的WINVER = 0x0600 的系统环境（这里指明了系统为Vista），所以要改变就要自己手动添加targerver.h)
根据targetver.h头文件里的下列定义：

#ifndef WINVER                  // 指定要求的最低平台是 Windows Vista。

#define WINVER 0x0600           // 将此值更改为相应的值，以适用于 Windows 的其他版本。

#endif

 #ifndef _WIN32_WINNT            // 指定要求的最低平台是 Windows Vista。

#define _WIN32_WINNT 0x0600     // 将此值更改为相应的值，以适用于 Windows 的其他版本。

#endif

PS：0×0500 表示Windows 2000，0×0501为Windows XP，0×0502为Windows Server 2003，0×0600 为 Windows Vista。
2、关于DX8SDK使用中link时出现的libci.lib无法找到的问题

最近开发过程中碰到了用DX8 SDK编译项目时,在link的时候,无法打开libci.lib的问题.

    LINK:fatal error  LNK1104:无法打开文件:libci.lib"

解决办法如下:

选择工程的属性,在linker选项中选择Command line ,增加下面一行:

      /nodefaultlib:libci 

原因：

出现在Vc9中,可能没有选择“安装旧的iostream库”.导致这个问题.在我看来,还是微软的问题.

3、模板特殊化(Template specialization)

模板的特殊化是当模板中的pattern有确定的类型时，模板有一个具体的实现。例如假设我们的类模板pair 包含一个取模计算（module operation）的函数，而我们希望这个函数只有当对象中存储的数据为整型(int)的时候才能工作，其他时候，我们需要这个函数总是返回0。这可以通过下面的代码来实现：

template <class T>

class Pair {

T value1, value2;

public:

Pair (T first, T second){

value1=first;

value2=second;

}

T module () {return 0;}

};

template <>

class Pair<int> {

int value1, value2;

public:

Pair (int first, int second){

value1=first;

value2=second;

}

int module ();

};

//在模板特例化中,NET的特性

template<> int Pair<int>::module() {

return value1%value2;

}

这里要注意,在.NET中template<>是不需要的,否则会发生

Compiler Error C2910

Error Message

'function' : cannot be explicitly specialized错误,

见:http://msdn.microsoft.com/en-us/library/cx7k7hcf(VS.80).aspx

4、STLport VS VS2008：

因为VC6对标准C++的支持不够，所以我们用了STLport库，然而在VS2008下MS的已经差不多和标准相同了啊，所以，没有必要在使用STLport库。在整理工程中，把其去掉。

5、旧的CRT库和新的安全CRT库引起的C4996告警

解决了环境变量设置不匹配导致的问题后，编译过程就真正开始了，不过首先映入眼帘的应该是成堆的C4996编译告警，对每个使用了含字符串参数的CRT库函数都会有C4996编译告警，一个典型的输出如下所示：

f:/project/...../commonfunc.cpp(280) : warning C4996: 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
e:/software/microsoft visual studio 9.0/vc/include/string.h(74) : see declaration of 'strcpy'

    MSDN online 是这样解释的：为了显著增加CRT库的安全性，许多CRT函数都有了一个更安全的新版本，新版本和旧版本的区别就是新版本函数名多了一个_s后缀。只要一个CRT函数有新的安全版本，编译器就会产生一个C4996告警，不过，出现这个告警的目的并不是说旧版本的CRT函数将淡出CRT库，告警出现只是为了提醒程序员这个函数有更安全的版本存在。一种安全的或者是被鼓励的做法是用安全版本的函数替换现有的CRT函数，不过对于一个有相当代码量的项目，替换工作量也是巨大的，这可不是用名称查找、替换就能简单解决的问题，因为许多安全版本的CRT函数参数个数也发生了变化。也可以用预处理指令消除这个告警：
#pragma warning( disable : 4996 )
或者定义 _CRT_SECURE_NO_WARNINGS 压制这个告警（在stdafx.h中define或在项目属性中设置预处理符号,PreProcessor Definitions）。

除了C语言的CRT函数外，POSIX 兼容函数也存在这个告警，解决方法是用POSIX标准名称替换（比如access换成_access）或者是定义 _CRT_NONSTDC_NO_WARNINGS 压制这个告警（方法同上）。

 

6、新的C++编译器不再支持默认类型的变量定义

错误现象是：
f:/project/...../WzCheckBox.cpp(464) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int

产生这个错误的原因是程序中出现了这样的代码：

const some_const_var = 10;

或

static some_static_bool = FALSE;

新的C++编译器严格按照C++标准，不再支持默认类型的变量定义方式，必须严格指定变量类型，如下使用：

const int some_const_var = 10;

或

static BOOL some_static_bool = FALSE;
7、for 语句的变量作用域问题

考察下面的代码：

for(int i = 0; i < 120; i++)
{
    if(something_happen)
    {
         break;
    }
.............
}

if(i < 120)
{
    //something happen
}

在VC6的编译器中，这样的代码是没有问题的，因为VC6的编译器为了兼容旧的Microsoft C/C++编译器，没有严格按照C++标准执行，但是从VC7开始，VC的编译器开始遵守C++标准，所以就会出现“变量i没有定义的错误”。解决的方法也很简单，按照Jim Hyslop 和 Herb Sutter的经典对话系列的第四篇中的方法，改成如下就可以了：

int i;
for(i = 0; i < 120; i++)

8、字符串函数的返回值问题

    strchr(_tcschr)、strpbrk(_tcspbrk ??)、strrchr(_tcsrchr)和strstr(_tcsstr)这四个函数在VC6的CRT库中定义的返回值都是char *(TCHAR *)，所以以前的代码通常是这样使用的：

TCHAR *cp = _tcschr( pszPath, _T('//') );
//使用*cp，可以通过cp指针修改pszPath的内容

这其实是一个“漏洞”，因为如果pszPath是const char(TCHAR) *字符串，那么就表示它不希望修改字符串的内容，但是调用strchr(_tcschr)函数后就可以通过cp指针修改其内容了，这岂不荒谬？所有在新版本的CRT库中，这几个函数的返回值都改成const char *，这就会导致上面的代码产生编译错误。建议的修改方式是改成如下方式：

const TCHAR *cp = _tcschr( pszPath, _T('//') );
//不能再通过cp指针修改pszPath的内容

但是这样修改可能对代码的影响比较大，比如下面的代码：
TCHAR buf[256]; //局部缓冲区
......
TCHAR *cp = _tcschr( buf, _T('//') );
//作为局部缓冲区（非const），希望通过cp修改buf的内容

这种情况怎么办呢？对了，C++还有个const_cast操作符，这时就可以排上用场了：

TCHAR *cp = const_char<TCHAR *>(_tcschr( buf, _T('//') ));

不过上面的方法要慎用，除非确定buf是非const的，否则最好老老实实地修改代码。

10、类成员函数指针做为函数参数的“C3867”错误

考察下面的代码，CWzWindowsHook类的构造函数使用一个该类的成员函数指针，这样构造对象时可以选择消息过滤的handler，可以是MouseMsgFilter，也可以是KeyboardMsgFilter：

typedef BOOL (CWzWindowsHook::*FILTERPROC)(WPARAM wParam, LPARAM lParam);

// A hook used in customization sheet to filter keyboard/mouse events
class CWzWindowsHook
{
private:
    FILTERPROC m_pFilter;
    BOOL MouseMsgFilter(WPARAM wParam, LPARAM lParam);
    BOOL KeyboardMsgFilter(WPARAM wParam, LPARAM lParam);
public:
    CWzWindowsHook(FILTERPROC pFilter) : m_pFilter(pFilter)
旧的遗留代码存在这样的用法：

CWzWindowsHook mouseHooker(CWzWindowsHook::MouseMsgFilter);

在VC6的编译器下编译可能没有问题，但是在VC9的编译器下编译会有如下报错：

f:/project/...../WzWindowsHook.cpp(272) : error C3867: 'CWzWindowsHook::MouseMsgFilter': function call missing argument list; use '&CWzWindowsHook::MouseMsgFilter' to create a pointer to member

虽然C++从C继承来了函数名即是函数地址的语法规则，但是根据C++的标准，类成员函数的指针仍然需要一个取地址符“&”。解决方法很简单，按照提示改成如下代码即可：

CWzWindowsHook mouseHooker(&CWzWindowsHook::MouseMsgFilter);

11、wchar_t *类型与USHORT *的转换错误

    VC6的编译器不支持wchar_t数据类型，wchar_t实际上被定义成unsigned short，VC9的编译器已经支持wchar_t为内置数据类型，但是由一个编译选项控制，这个选项默认是打开的，也就是将wchar_t作为编译器的内置数据类型。但是OLECHAR和WCHAR的定义仍然是unsigned short，在VC6的编译环境中，两者的指针都是USHORT *，相互赋值和做为函数参数传递没有问题，但是如果wchar_t作为编译器的内置数据类型，那就意味着wchar_t *与OLECHAR *或WCHAR *是两种不同类型的指针，相互赋值就会报编译错误，下面的信息就是一个典型的错误输出：

f:/project/...../shellpidl.cpp(290) : error C2664: 'MultiByteToWideChar' : cannot convert parameter 5 from 'USHORT *' to 'LPWSTR'
        Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast

解决的方法就是使用C++的reinterpret_cast操作符或使用C-style强制转换，当然也可以在项目属性设置中关闭前面提到的那个选项（这个偶美试过，不知道会不会有其它问题）。