从VC6.0平台级到VS2008平台

余生颓废 提交于 2020-01-09 07:31:18
从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强制转换,当然也可以在项目属性设置中关闭前面提到的那个选项(这个偶美试过,不知道会不会有其它问题)。

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!