下载
加入VIP
  • 专属下载特权
  • 现金文档折扣购买
  • VIP免费专区
  • 千万文档免费下载

上传资料

关闭

关闭

关闭

封号提示

内容

首页 VC6转VS2008

VC6转VS2008.pdf

VC6转VS2008

88cheng96
2012-04-25 0人阅读 举报 0 0 暂无简介

简介:本文档为《VC6转VS2008pdf》,可适用于高等教育领域

首先可以直接用VisualStudio的打开VC的工作区文件和项目文件(dsw和dsp)并将其升级为VS的解决方案格式和项目格式(sln和vcproj)VC的编译器相对于VC有了很大的变化一些编译参数和链接参数被废弃(比如map:line)有一些改变了名称,还有新增的选项不过不用担心升级过程会自动对其进行转换最终都会得到一个正确的解决方案和VC项目文件这个过程不会遇到太多的麻烦问题都出在随后的编译过程中下面就将我在移植的过程中遇到的问题和我的解决方法总结一下希望对还在用VC维护代码的朋友有所帮助。一、WINWINNT与WINIE设置冲突WINWINNT与WINIE设置不兼容会导致如下C致命错误:StdAfxcppc:programfilesmicrosoftsdkswindowsvaincludesdkddkverh():fatalerrorC:#error:WINWINNTsettingsconflictswithWINIEsettingStdAfxcpp通常是项目中第一个编译的文件这个错误将导致编译无法继续进行。产生这个错误的原因是原因是WINWINNT的版本定义太老老的VC代码对WINWINNT的典型设置是:#ifndefWINWINNT#defineWINWINNTx#endifx相对于VS所带的PlarformSDK(在文件sdkddkverh中)中WINIE的定义来说太老了导致不兼容可以将其改成x或更高的版本避免这个问题如下所示:#ifndefWINWINNT#defineWINWINNTx#endif也可以将这三行WINWINNT定义删除这样就会使用PlarformSDK中的WINWINNT定义自然就不存在不兼容问题了。不过出于对老版本VC的兼容考虑(毕竟以后可能还要使用VC编译代码)最好这样修改:#ifMSCVER<=MFCorearlier#ifndefWINWINNT#defineWINWINNTx#endif#endif二、afximplh文件中的语法错误MFC出现的时候STL还没有成为C的标准所以MFC使用一套自己的模版库比如CArray、CList、CMap等等这些类型声明都在afximplh文件中。原来在VC编译器适用的模版语法可能不适用VC特别是当以下四个环境变量设置不兼容时就会出现这个编译错误大致情况如下:e:softwaremicrosoftvisualstudiovcatlmfcsrcmfcafximplh():errorC:syntaxerror:''e:softwaremicrosoftvisualstudiovcatlmfcsrcmfcafximplh():errorC:unexpectedtoken(s)preceding''e:softwaremicrosoftvisualstudiovcatlmfcsrcmfcafximplh():errorC:syntaxerror:''e:softwaremicrosoftvisualstudiovcatlmfcsrcmfcafximplh():errorC:unexpectedtoken(s)preceding''合理调整stdafxh中WINVER、WINWINNT、WINWINDOWS和WINIE的设置可以避免这个问题将三个与Windows版本有关的环境变量设置为x或更高版本将IE版本的环境变量设置为x以后的版本就可以解决这个问题。当然考虑到与旧的VC代码兼容可以采用上一个问题中提到的最后一个解决办法用MSCVER进行隔离。三、旧的CRT库和新的安全CRT库引起的C告警解决了环境变量设置不匹配导致的问题后编译过程就真正开始了不过首先映入眼帘的应该是成堆的C编译告警对每个使用了含字符串参数的CRT库函数都会有C编译告警一个典型的输出如下所示:f:projectcommonfunccpp():warningC:'strcpy':ThisfunctionorvariablemaybeunsafeConsiderusingstrcpysinsteadTodisabledeprecation,useCRTSECURENOWARNINGSSeeonlinehelpfordetailse:softwaremicrosoftvisualstudiovcincludestringh():seedeclarationof'strcpy'MSDNonline是这样解释的:为了显著增加CRT库的安全性许多CRT函数都有了一个更安全的新版本新版本和旧版本的区别就是新版本函数名多了一个s后缀。只要一个CRT函数有新的安全版本编译器就会产生一个C告警不过出现这个告警的目的并不是说旧版本的CRT函数将淡出CRT库告警出现只是为了提醒程序员这个函数有更安全的版本存在。一种安全的或者是被鼓励的做法是用安全版本的函数替换现有的CRT函数不过对于一个有相当代码量的项目替换工作量也是巨大的这可不是用名称查找、替换就能简单解决的问题因为许多安全版本的CRT函数参数个数也发生了变化。也可以用预处理指令消除这个告警:#pragmawarning(disable:)或者定义CRTSECURENOWARNINGS压制这个告警(在stdafxh中define或在项目属性中设置预处理符号,PreProcessorDefinitions)。除了C语言的CRT函数外POSIX兼容函数也存在这个告警解决方法是用POSIX标准名称替换(比如access换成access)或者是定义CRTNONSTDCNOWARNINGS压制这个告警(方法同上)。四、“CWinApp::EnabledControls”引起的C告警这个是编译使用了老的向导生成的MFC代码时遇到的问题一个典型的告警信息输出如下所示:CrpFileCrackcppf:projectcrpfilecrackcpp():warningC:'CWinApp::EnabledControls':CWinApp::EnabledControlsisnolongerneededYoushouldremovethiscalle:softwaremicrosoftvisualstudiovcatlmfcincludeafxwinh():seedeclarationof'CWinApp::EnabledControls'通常向导生成的代码是:#ifdefAFXDLLEnabledControls()CallthiswhenusingMFCinasharedDLL#elseEnabledControlsStatic()CallthiswhenlinkingtoMFCstatically#endif这两个函数的调用是旧的MFC版本对新版本的操作系统特性的支持在新的(那个时候是新的)Windows平台上要这样调用一下才能使用新的WindowsD样式的控件否则就是老的Win样子的控件。想当初喜欢OWL就是因为感觉它的控件比较“酷”比如那个带底纹的对话框菱形的checkbox还有带图标的“OK”按钮看到MFC作出来的灰灰的界面就觉得土不过后来就知道MFC做界面也是很漂亮的比如我做的。。。。再打住。对于新的MFC版本来说已经不需要再调用这两个函数了参考前面的方法用MSCVER对其隔离就行了:#ifMSCVER<=MFCorearlier#ifdefAFXDLLEnabledControls()CallthiswhenusingMFCinasharedDLL#elseEnabledControlsStatic()CallthiswhenlinkingtoMFCstatically#endif#endif五、def文件引起的连接告警对于普通的DLL项目中使用的def文件通常会引起LNK链接告警如下所示:ComFuncdef():warningLNK:DESCRIPTIONstatementnotsupportedforthetargetplatformignoredCreatinglibraryDebugComFunclibandobjectDebugComFuncexp一个典型的def文件通常有以下内容:LIBRARY"XorCryptor"DESCRIPTION'XorCryptorWindowsDynamicLinkLibrary'EXPORTSExplicitexportscangohere消除这个连接告警的方法就是从def文件中删除DESCRIPTION描述信息不过这个告警也不是什么大问题不删也可以。另一个可能产生的连接告警是LNK通常出现在ocx控件和com组件的项目中一个典型输出是:LinkingPlusInModuledef:warningLNK:exportedsymbol'DllCanUnloadNow'shouldnotbeassignedanordinalPlusInModuledef:warningLNK:exportedsymbol'DllGetClassObject'shouldnotbeassignedanordinalPlusInModuledef:warningLNK:exportedsymbol'DllRegisterServer'shouldnotbeassignedanordinalPlusInModuledef:warningLNK:exportedsymbol'DllUnregisterServer'shouldnotbeassignedanordinal出现这个告警的原因是旧的项目的def文件通常这样定义ocx和com必需的四个导出函数:EXPORTSDllCanUnloadNowPRIVATEDllGetClassObjectPRIVATEDllRegisterServerPRIVATEDllUnregisterServerPRIVATE其中为这四个重要的导出函数指定了四个顺序号。Windows平台上通常用两种方式定位DLL文件中的导出函数一种是根据导出函数名称一种是根据顺序号上学时曾经写过一个显示图片的程序能处理大多数当时流行的图像格式文件唯独jpeg格式的搞不定有一次看到一个图像处理软件中包含了一个LoadJpegdll很显然这个DLL是处理jpeg格式的图像文件的嘛于是赶快用dependslook了一下顿时高喊:鬼啊~~~。原来这个depends竟然查不到导出函数的名字后来才知道还有NONAME参数强制用顺序号定位导出函数于是就常常弄个没有导出函数名字的DLL到处show。。。。嗯又扯远了。话说为什么旧的系统要以此指定这四个导出函数的顺序号我就没有研究了反正现在不需要指定了只要将之类的删除就行了不过不删好像也没什么问题它们会被自动忽略。六、使用MFC的消息映射宏引起的编译错误错误现象之一:f:projectplusmaindlgcpp():errorC:'staticcast':cannotconvertfrom'void(thiscallCPlusMainDlg::*)(int,BOOL)'to'LRESULT(thiscallCWnd::*)(WPARAM,LPARAM)'Noneofthefunctionswiththisnameinscopematchthetargettype错误现象之二:f:projectcrpfileopavdlgcpp():errorC:'staticcast':cannotconvertfrom'LRESULT(thiscallCCrpFileOpavDlg::*)(LPCTSTR,int)'to'LRESULT(thiscallCWnd::*)(WPARAM,LPARAM)'Noneofthefunctionswiththisnameinscopematchthetargettype以上两个编译错误产生是因为新旧版本的MFC中对ONMESSAGE消息映射宏定义不同引起的先看看老版本的MFC的ONMESSAGE消息宏定义:#defineONMESSAGE(message,memberFxn){message,,,,AfxSiglwl,(AFXPMSG)(AFXPMSGW)(LRESULT(AFXMSGCALLCWnd::*)(WPARAM,LPARAM))memberFxn},再看看新版本的ONMESSAGE定义:#defineONMESSAGE(message,memberFxn){message,,,,AfxSiglwl,(AFXPMSG)(AFXPMSGW)(staticcast<LRESULT(AFXMSGCALLCWnd::*)(WPARAM,LPARAM)>(memberFxn))},注意函数类型没有变化都是:LRESULT(AFXMSGCALLCWnd::*)(WPARAM,LPARAM)类型的函数指针(CWnd以及派生类的类成员函数指针)区别之处是新的ONMESSAGE宏使用C的staticcast操作符代替了C类型的强制转换。产生这两个错误其实是因为用户没有按照ONMESSAGE宏的约定声明和定义消息响应函数造成的比如对于某些不需要处理返回值的消息响应函数用户通常这样声明和定义消息响应函数:在头文件中声明:afxmsgvoidOnFileProcess(WPARAMwParam,LPARAMlParam)在源文件中实现:voidCCrpFileOpavDlg::OnFileProcess(WPARAMwParam,LPARAMlParam){}或者更过分一些直接指定为实际参数类型:在头文件中声明:afxmsgvoidOnFileProcess(LPCTSTRlpszMessage,intnPercent)在源文件中实现:voidCCrpFileOpavDlg::OnFileProcess(LPCTSTRlpszMessage,intnPercent){}旧版本的ONMESSAGE使用了C类型的强制转换宏解开后的代码后不会产生错误信息但是改成对类型检查很严格的staticcast操作符时就出问题了因为通不过staticcast操作符的检查。解决方法就是修改代码同时吸取教训普遍使用的方法并不一定就能约定俗成一切还是要按照规矩来。错误现象之三:f:projectWzButtoncpp():errorC:'staticcast':cannotconvertfrom'UINT(thiscallCWzButton::*)(CPoint)'to'LRESULT(thiscallCWnd::*)(CPoint)'Castfrombasetoderivedrequiresdynamiccastorstaticcast出现这个错误的原因可是“人力不可抗拒”之原因造成的因为旧版本的ONWMNCHITTEST宏使用了UINT(thiscallCWzButton::*)(CPoint)类型的类成员函数指针其定义如下:#defineONWMNCHITTEST(){WMNCHITTEST,,,,AfxSigwp,(AFXPMSG)(AFXPMSGW)(UINT(AFXMSGCALLCWnd::*)(CPoint))OnNcHitTest},但是新版本变成了:#defineONWMNCHITTEST(){WMNCHITTEST,,,,AfxSiglp,(AFXPMSG)(AFXPMSGW)(staticcast<LRESULT(AFXMSGCALLCWnd::*)(CPoint)>(ThisClass::OnNcHitTest))},注意返回值类型由UINT改成了LRESULT再加上staticcast的严格检查所以就出错了。修改的方法就是将你的OnNcHitTest函数由:afxmsgUINTOnNcHitTest(CPointpoint)改成:afxmsgLRESULTOnNcHitTest(CPointpoint)不必太在意这个不是你的错不过如果你要维护一个老的界面库(通常很多控件的subclass都会用到ONWMNCHITTEST)改起来还是很痛苦地不扯了继续下一个。七、statregcpp和atlimplcpp的废弃(obsolete)问题在编译老的ATL向导生成的代码时会遇到下面的编译输出:StdAfxcppstatregcppisobsoletePleaseremoveitfromyourprojectatlimplcppisobsoletePleaseremoveitfromyourproject因为老的ATL向导生成的代码通常在stdafxcpp文件中添加以下代码:#ifdefATLSTATICREGISTRY#include#include#endif#include根据提示删除#include和#include两行代码就行了不过更好的办法是这样改:#ifdefATLSTATICREGISTRY#include#ifMSCVER<=MFCorearlier#include#endif#endif#ifMSCVER<=MFCorearlier#include#endif八、新的C编译器不再支持默认类型的变量定义错误现象是:f:projectWzCheckBoxcpp():errorC:missingtypespecifierintassumedNote:Cdoesnotsupportdefaultint产生这个错误的原因是程序中出现了这样的代码:constsomeconstvar=或staticsomestaticbool=FALSE新的C编译器严格按照C标准不再支持默认类型的变量定义方式必须严格指定变量类型如下使用:constintsomeconstvar=或staticBOOLsomestaticbool=FALSE九、for语句的变量作用域问题考察下面的代码:for(inti=i<i){if(somethinghappen){break}}if(i<){somethinghappen}在VC的编译器中这样的代码是没有问题的因为VC的编译器为了兼容旧的MicrosoftCC编译器没有严格按照C标准执行但是从VC开始VC的编译器开始遵守C标准所以就会出现“变量i没有定义的错误”。解决的方法也很简单按照JimHyslop和HerbSutter的经典对话系列的第四篇中的方法改成如下就可以了:intifor(i=i<i)十、字符串函数的返回值问题strchr(tcschr)、strpbrk(tcspbrk)、strrchr(tcsrchr)和strstr(tcsstr)这四个函数在VC的CRT库中定义的返回值都是char*(TCHAR*)所以以前的代码通常是这样使用的:TCHAR*cp=tcschr(pszPath,T(''))使用*cp可以通过cp指针修改pszPath的内容这其实是一个“漏洞”因为如果pszPath是constchar(TCHAR)*字符串那么就表示它不希望修改字符串的内容但是调用strchr(tcschr)函数后就可以通过cp指针修改其内容了这岂不荒谬?所有在新版本的CRT库中这几个函数的返回值都改成constchar*这就会导致上面的代码产生编译错误。建议的修改方式是改成如下方式:constTCHAR*cp=tcschr(pszPath,T(''))不能再通过cp指针修改pszPath的内容但是这样修改可能对代码的影响比较大比如下面的代码:TCHARbuf局部缓冲区TCHAR*cp=tcschr(buf,T(''))作为局部缓冲区(非const)希望通过cp修改buf的内容这种情况怎么办呢?对了C还有个constcast操作符这时就可以排上用场了:TCHAR*cp=constchar(tcschr(buf,T('')))不过上面的方法要慎用除非确定buf是非const的否则最好老老实实地修改代码。十一、类成员函数指针做为函数参数的“C”错误考察下面的代码CWzWindowsHook类的构造函数使用一个该类的成员函数指针这样构造对象时可以选择消息过滤的handler可以是MouseMsgFilter也可以是KeyboardMsgFilter:typedefBOOL(CWzWindowsHook::*FILTERPROC)(WPARAMwParam,LPARAMlParam)AhookusedincustomizationsheettofilterkeyboardmouseeventsclassCWzWindowsHook{private:FILTERPROCmpFilterBOOLMouseMsgFilter(WPARAMwParam,LPARAMlParam)BOOLKeyboardMsgFilter(WPARAMwParam,LPARAMlParam)public:CWzWindowsHook(FILTERPROCpFilter):mpFilter(pFilter)旧的遗留代码存在这样的用法:CWzWindowsHookmouseHooker(CWzWindowsHook::MouseMsgFilter)在VC的编译器下编译可能没有问题但是在VC的编译器下编译会有如下报错:f:projectWzWindowsHookcpp():errorC:'CWzWindowsHook::MouseMsgFilter':functioncallmissingargumentlistuse'CWzWindowsHook::MouseMsgFilter'tocreateapointertomember虽然C从C继承来了函数名即是函数地址的语法规则但是根据C的标准类成员函数的指针仍然需要一个取地址符“”。解决方法很简单按照提示改成如下代码即可:CWzWindowsHookmouseHooker(CWzWindowsHook::MouseMsgFilter)十二、wchart*类型与USHORT*的转换错误VC的编译器不支持wchart数据类型wchart实际上被定义成unsignedshortVC的编译器已经支持wchart为内置数据类型但是由一个编译选项控制这个选项默认是打开的也就是将wchart作为编译器的内置数据类型。但是OLECHAR和WCHAR的定义仍然是unsignedshort在VC的编译环境中两者的指针都是USHORT*相互赋值和做为函数参数传递没有问题但是如果wchart作为编译器的内置数据类型那就意味着wchart*与OLECHAR*或WCHAR*是两种不同类型的指针相互赋值就会报编译错误下面的信息就是一个典型的错误输出:f:projectshellpidlcpp():errorC:'MultiByteToWideChar':cannotconvertparameterfrom'USHORT*'to'LPWSTR'Typespointedtoareunrelatedconversionrequiresreinterpretcast,Cstylecastorfunctionstylecast解决的方法就是使用C的reinterpretcast操作符或使用Cstyle强制转换当然也可以在项目属性设置中关闭前面提到的那个选项(这个偶美试过不知道会不会有其它问题)。

用户评价(0)

关闭

新课改视野下建构高中语文教学实验成果报告(32KB)

抱歉,积分不足下载失败,请稍后再试!

提示

试读已结束,如需要继续阅读或者下载,敬请购买!

文档小程序码

使用微信“扫一扫”扫码寻找文档

1

打开微信

2

扫描小程序码

3

发布寻找信息

4

等待寻找结果

我知道了
评分:

/8

VC6转VS2008

VIP

在线
客服

免费
邮箱

爱问共享资料服务号

扫描关注领取更多福利