VC6升至VC的常见错误及处理Word文档格式.docx
- 文档编号:21470963
- 上传时间:2023-01-30
- 格式:DOCX
- 页数:9
- 大小:22.33KB
VC6升至VC的常见错误及处理Word文档格式.docx
《VC6升至VC的常见错误及处理Word文档格式.docx》由会员分享,可在线阅读,更多相关《VC6升至VC的常见错误及处理Word文档格式.docx(9页珍藏版)》请在冰豆网上搜索。
#endif
二、afximpl.h文件中的语法错误
MFC出现的时候STL还没有成为C++的标准,所以MFC使用一套自己的模版库,比如CArray、CList、CMap等等,这些类型声明都在afximpl.h文件中。
原来在VC6编译器适用的模版语法可能不适用VC9,特别是当以下四个环境变量设置不兼容时,就会出现这个编译错误,大致情况如下:
e:
\software\microsoftvisualstudio9.0\vc\atlmfc\src\mfc\afximpl.h(625):
errorC2059:
syntaxerror:
'
<
L_TYPE_raw>
'
errorC2238:
unexpectedtoken(s)preceding'
;
\software\microsoftvisualstudio9.0\vc\atlmfc\src\mfc\afximpl.h(629):
合理调整stdafx.h中WINVER、_WIN32_WINNT、_WIN32_WINDOWS和_WIN32_IE的设置可以避免这个问题,将三个与Windows版本有关的环境变量设置为0x0501或更高版本,将IE版本的环境变量设置为0x0500以后的版本就可以解决这个问题。
当然,考虑到与旧的VC6代码兼容,可以采用上一个问题中提到的最后一个解决办法,用_MSC_VER进行隔离。
三、旧的CRT库和新的安全CRT库引起的C4996告警
解决了环境变量设置不匹配导致的问题后,编译过程就真正开始了,不过首先映入眼帘的应该是成堆的C4996编译告警,对每个使用了含字符串参数的CRT库函数都会有C4996编译告警,一个典型的输出如下所示:
f:
\project\.....\commonfunc.cpp(280):
warningC4996:
strcpy'
:
Thisfunctionorvariablemaybeunsafe.Considerusingstrcpy_sinstead.Todisabledeprecation,use_CRT_SECURE_NO_WARNINGS.Seeonlinehelpfordetails.
\software\microsoftvisualstudio9.0\vc\include\string.h(74):
seedeclarationof'
MSDNonline是这样解释的:
为了显著增加CRT库的安全性,许多CRT函数都有了一个更安全的新版本,新版本和旧版本的区别就是新版本函数名多了一个_s后缀。
只要一个CRT函数有新的安全版本,编译器就会产生一个C4996告警,不过,出现这个告警的目的并不是说旧版本的CRT函数将淡出CRT库,告警出现只是为了提醒程序员这个函数有更安全的版本存在。
一种安全的或者是被鼓励的做法是用安全版本的函数替换现有的CRT函数,不过对于一个有相当代码量的项目,替换工作量也是巨大的,这可不是用名称查找、替换就能简单解决的问题,因为许多安全版本的CRT函数参数个数也发生了变化。
也可以用预处理指令消除这个告警:
#pragmawarning(disable:
4996)
或者定义_CRT_SECURE_NO_WARNINGS压制这个告警(在stdafx.h中define或在项目属性中设置预处理符号,PreProcessorDefinitions)。
除了C语言的CRT函数外,POSIX兼容函数也存在这个告警,解决方法是用POSIX标准名称替换(比如access换成_access)或者是定义_CRT_NONSTDC_NO_WARNINGS压制这个告警(方法同上)。
四、“CWinApp:
Enable3dControls”引起的C4996告警
这个是编译使用了老的向导生成的MFC代码时遇到的问题,一个典型的告警信息输出如下所示:
CrpFileCrack.cpp
\project\.....\crpfilecrack.cpp(52):
CWinApp:
Enable3dControls'
CWinApp:
Enable3dControlsisnolongerneeded.Youshouldremovethiscall.
e:
\software\microsoftvisualstudio9.0\vc\atlmfc\include\afxwin.h(4818):
通常向导生成的代码是:
#ifdef_AFXDLL
Enable3dControls();
//CallthiswhenusingMFCinasharedDLL
#else
Enable3dControlsStatic();
//CallthiswhenlinkingtoMFCstatically
这两个函数的调用是旧的MFC版本对新版本的操作系统特性的支持,在新的(那个时候是新的)Windows95平台上要这样调用一下才能使用新的Windows3D样式的控件,否则就是老的Win3.2样子的控件。
想当初喜欢OWL就是因为感觉它的控件比较“酷”,比如那个带底纹的对话框,菱形的checkbox,还有带图标的“OK”按钮,看到MFC作出来的灰灰的界面就觉得土,不过后来就知道MFC做界面也是很漂亮的,比如我做的。
。
,再打住。
对于新的MFC版本来说已经不需要再调用这两个函数了,参考前面的方法,用_MSC_VER对其隔离就行了:
#ifdef_AFXDLL
#else
五、.def文件引起的连接告警
对于普通的DLL项目中使用的.def文件通常会引起LNK4017链接告警,如下所示:
.\ComFunc.def(4):
warningLNK4017:
DESCRIPTIONstatementnotsupportedforthetargetplatform;
ignored
Creatinglibrary.\..\Debug/ComFunc.libandobject.\..\Debug/ComFunc.exp
一个典型的.def文件通常有以下内容:
LIBRARY
"
XorCryptor"
DESCRIPTION'
XorCryptorWindowsDynamicLinkLibrary'
EXPORTS
;
Explicitexportscangohere
..................
消除这个连接告警的方法就是从.def文件中删除DESCRIPTION描述信息,不过这个告警也不是什么大问题,不删也可以。
另一个可能产生的连接告警是LNK4222,通常出现在ocx控件和com组件的项目中,一个典型输出是:
Linking...
.\PlusInModule.def:
warningLNK4222:
exportedsymbol'
DllCanUnloadNow'
shouldnotbeassignedanordinal
DllGetClassObject'
DllRegisterServer'
DllUnregisterServer'
shouldnotbeassignedanordinal
出现这个告警的原因是旧的项目的.def文件通常这样定义ocx和com必需的四个导出函数:
DllCanUnloadNow
@1PRIVATE
DllGetClassObject
@2PRIVATE
DllRegisterServer
@3PRIVATE
DllUnregisterServer
@4PRIVATE
其中为这四个重要的导出函数指定了四个顺序号。
Windows平台上通常用两种方式定位DLL文件中的导出函数,一种是根据导出函数名称,一种是根据顺序号,上学时曾经写过一个显示图片的程序,能处理大多数当时流行的图像格式文件,唯独jpeg格式的搞不定,有一次看到一个图像处理软件中包含了一个LoadJpeg.dll,很显然这个DLL是处理jpeg格式的图像文件的嘛,于是赶快用dependslook了一下,顿时高喊:
鬼啊~~~。
原来这个depends竟然查不到导出函数的名字,后来才知道还有NONAME参数强制用顺序号定位导出函数,于是就常常弄个没有导出函数名字的DLL到处show。
嗯,又扯远了。
话说为什么旧的系统要以此指定这四个导出函数的顺序号我就没有研究了,反正现在不需要指定了,只要将@1,@2之类的删除就行了,不过不删好像也没什么问题,它们会被自动忽略。
六、使用MFC的消息映射宏引起的编译错误
错误现象之一:
\project\.....\plusmaindlg.cpp(220):
errorC2440:
static_cast'
:
cannotconvertfrom'
void(__thiscallCPlusMainDlg:
*)(int,BOOL)'
to'
LRESULT(__thiscallCWnd:
*)(WPARAM,LPARAM)'
Noneofthefunctionswiththisnameinscopematchthetargettype
错误现象之二:
\project\.....\crpfileopavdlg.cpp(87):
LRESULT(__thiscallCCrpFileOpavDlg:
*)(LPCTSTR,int)'
以上两个编译错误产生是因为新旧版本的MFC中对ON_MESSAGE消息映射宏定义不同引起的,先看看老版本的MFC的ON_MESSAGE消息宏定义:
#defineON_MESSAGE(message,memberFxn)\
{message,0,0,0,AfxSig_lwl,\
(AFX_PMSG)(AFX_PMSGW)(LRESULT(AFX_MSG_CALLCWnd:
*)(WPARAM,LPARAM))&
memberFxn},
再看看新版本的ON_MESSAGE定义:
(AFX_PMSG)(AFX_PMSGW)\
(static_cast<
LRESULT(AFX_MSG_CALLCWnd:
*)(WPARAM,LPARAM)>
\
(memberFxn))},
注意,函数类型没有变化,都是:
LRESULT(AFX_MSG_CALLCWnd:
*)(WPARAM,LPARAM);
类型的函数指针(CWnd以及派生类的类成员函数指针),区别之处是新的ON_MESSAGE宏使用C++的static_cast操作符代替了C类型的强制转换。
产生这两个错误其实是因为用户没有按照ON_MESSAGE宏的约定声明和定义消息响应函数造成的,比如,对于某些不需要处理返回值的消息响应函数,用户通常这样声明和定义消息响应函数:
在头文件中声明:
afx_msgvoidOnFileProcess(WPARAMwParam,LPARAMlParam);
在源文件中实现:
voidCCrpFileOpavDlg:
OnFileProcess(WPARAMwParam,LPARAMlParam)
{
.......
}
或者更过分一些,直接指定为实际参数类型:
afx_msgvoidOnFileProcess(LPCTSTRlpszMessage,intnPercent);
OnFileProcess(LPCTSTRlpszMessage,intnPercent)
旧版本的ON_MESSAGE使用了C类型的强制转换,宏解开后的代码后不会产生错误信息,但是改成对类型检查很严格的static_cast操作符时就出问题了,因为通不过static_cast操作符的检查。
解决方法就是修改代码,同时吸取教训,普遍使用的方法并不一定就能约定俗成,一切还是要按照规矩来。
错误现象之三:
\project\.....\WzButton.cpp(74):
UINT(__thiscallCWzButton:
*)(CPoint)'
Castfrombasetoderivedrequiresdynamic_castorstatic_cast
出现这个错误的原因可是“人力不可抗拒”之原因造成的,因为旧版本的ON_WM_NCHITTEST宏使用了
*)(CPoint);
类型的类成员函数指针,其定义如下:
#defineON_WM_NCHITTEST()\
{WM_NCHITTEST,0,0,0,AfxSig_wp,\
(AFX_PMSG)(AFX_PMSGW)(UINT(AFX_MSG_CALLCWnd:
*)(CPoint))&
OnNcHitTest},
但是新版本变成了:
{WM_NCHITTEST,0,0,0,AfxSig_l_p,\
*)(CPoint)>
(&
ThisClass:
OnNcHitTest))},
注意返回值类型由UINT改成了LRESULT,再加上static_cast的严格检查,所以就出错了。
修改的方法就是将你的OnNcHitTest函数由:
afx_msgUINTOnNcHitTest(CPointpoint);
改成:
afx_msgLRESULTOnNcHitTest(CPointpoint);
不必太在意,这个不是你的错,不过,如果你要维护一个老的界面库(通常很多控件的subclass都会用到ON_WM_NCHITTEST),改起来还是很痛苦地,不扯了,继续下一个。
七、statreg.cpp和atlimpl.cpp的废弃(obsolete)问题
在编译老的ATL向导生成的代码时,会遇到下面的编译输出:
statreg.cppisobsolete.Pleaseremoveitfromyourproject.
atlimpl.cppisobsolete.Pleaseremoveitfromyourproject.
因为老的ATL向导生成的代码通常在stdafx.cpp文件中添加以下代码:
#ifdef_ATL_STATIC_REGISTRY
#include<
statreg.h>
statreg.cpp>
atlimpl.cpp>
根据提示删除#include<
和#include<
两行代码就行了,不过更好的办法是这样改:
#endif
八、新的C++编译器不再支持默认类型的变量定义
错误现象是:
\project\.....\WzCheckBox.cpp(464):
errorC4430:
missingtypespecifier-intassumed.Note:
C++doesnotsupportdefault-int
产生这个错误的原因是程序中出现了这样的代码:
constsome_const_var=10;
或
staticsome_static_bool=FALSE;
新的C++编译器严格按照C++标准,不再支持默认类型的变量定义方式,必须严格指定变量类型,如下使用:
constintsome_const_var=10;
staticBOOLsome_static_bool=FALSE;
九、for语句的变量作用域问题
考察下面的代码:
for(inti=0;
i<
120;
i++)
if(something_happen)
{
break;
}
.............
if(i<
120)
//somethinghappen
在VC6的编译器中,这样的代码是没有问题的,因为VC6的编译器为了兼容旧的MicrosoftC/C++编译器,没有严格按照C++标准执行,但是从VC7开始,VC的编译器开始遵守C++标准,所以就会出现“变量i没有定义的错误”。
解决的方法也很简单,按照JimHyslop和HerbSutter的经典对话系列的第四篇中的方法,改成如下就可以了:
inti;
for(i=0;
i++)
十、字符串函数的返回值问题
strchr(_tcschr)、strpbrk(_tcspbrk?
?
)、strrchr(_tcsrchr)和strstr(_tcsstr)这四个函数在VC6的CRT库中定义的返回值都是char*(TCHAR*),所以以前的代码通常是这样使用的:
TCHAR*cp=_tcschr(pszPath,_T('
\\'
));
//使用*cp,可以通过cp指针修改pszPath的内容
这其实是一个“漏洞”,因为如果pszPath是c
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- VC6 升至 VC 常见 错误 处理