VC6轉(zhuǎn)到換高版本的問題及解決方法

1、VC6轉(zhuǎn)到換高版本的問題與解決方法 VS2008與VC6.0的變化剛從VC+6.0轉(zhuǎn)到VS2008，用著好不習(xí)慣，網(wǎng)上找到一帖子，轉(zhuǎn)給大家，希望會(huì)有幫助。-1.MessageBox（） VC+6.0：MessageBox("Hello,World!"); VS2008：MessageBox(L"Hello,World!"); 或 MessageBox(TEXT("Hello,World!"); 2.Combo box內(nèi)容添加方法 VC+6.0：Drop-Down List Box Control 的 Properties 中的 Dat

2、a 用 Ctrl-Enter 輸入 VS2008：更名為 Combo-Box Control ，并在右側(cè) Data 區(qū)域用 semicolons（即''）分隔輸入 3.從.net開始就沒有classwizard了,全部在屬性窗口里了 屬性窗口中有，閃電圖標(biāo)及右邊的都是，包括事件，消息，虛函數(shù)重載，加入變量則是在類標(biāo)上右擊->添加變量 4.消息映射 VS2005對消息的檢查更為嚴(yán)格，以前在VC6下完全正常運(yùn)行的消息映射在VS2005下編譯不通過 a,ON_MESSAGE(message,OnMyMessage); OnMyMessage返回值必須為LRESULT，其形式為：

3、afx_msg LRESULT OnMyMessage(WPARAM, LPARAM)； 如果不符合，則有錯(cuò)誤提示： error C2440: “static_cast”: 無法從“void (_thiscall CPppView:* )(WPARAM,LPARAM)”轉(zhuǎn)換為“LRESULT (_thiscall CWnd:* )(WPARAM,LPARAM)”error C2440: “static_cast”: 無法從“void (_thiscall CPppView:* )(void)”轉(zhuǎn)換為“LRESULT (_thiscall CWnd:* )(WPARAM,LPARAM)”b,在V

4、S2005中，OnMyMessage返回值必須為BOOL，且含有一個(gè) UINT 參數(shù)指出了命令I(lǐng)D，其形式為：afx_msg BOOL OnMyMessage(UINT)；如果不符合，則有錯(cuò)誤提示.如在VS6中，OnMyMessage2的定義為afx_msg BOOL OnViewZoomBar()時(shí)亦可正常編譯通過，但在VS2005下，有錯(cuò)誤提示： error C2440: “static_cast”: 無法從“BOOL (_thiscall CMainFrame:* )(void)”轉(zhuǎn)換為“BOOL (_thiscall CCmdTarget:* )(UINT)”error C2440:

5、“static_cast”: 無法從“BOOL (_thiscall CMainFrame:* )(void)”轉(zhuǎn)換為“BOOL (_thiscall CCmdTarget:* )(UINT)”5.字符處理 在c中廣泛使用的strcpy,strcat,strstr等等推薦使用更為安全strcpy_s,strcat_s,strstr_s等來代替. 6.數(shù)學(xué)函數(shù)檢查 VS2005中，數(shù)學(xué)函數(shù)的參數(shù)檢查更為嚴(yán)格，如pow(2, 45)會(huì)引起一個(gè)錯(cuò)誤提示如下： error C2668: “pow”: 對重載函數(shù)的調(diào)用不明確 d:program filesmicrosoft visual studio

6、8vcincludemath.h(575): 可能是“l(fā)ong double pow(long double,int)”d:program filesmicrosoft visual studio 8vcincludemath.h(527): 或“float pow(float,int)”d:program filesmicrosoft visual studio 8vcincludemath.h(489): 或“double pow(double,int)”試圖匹配參數(shù)列表“(int, int)”時(shí) 正確的使用為pow(2.0, 45) 7.更加符合C+標(biāo)準(zhǔn) 如在VS6中，在FOR循環(huán)中的循

7、環(huán)變量的定義的作用域延伸到循環(huán)體外，VS2005則修正了這樣的bug。 VC6: for(int i=0;i<100;i+)f2(); for(i = 1;i<10;i+)f1(); /i已經(jīng)定義 而有VS2005中，第二句的i必須重新定義-直接用Visual Studio 2008的打開VC6的工作區(qū)文件和項(xiàng)目文件（dsw和dsp），并將其升級(jí)為VS2008的解決方案格式和項(xiàng)目格式（sln和vcproj），VC9的編譯器相對于VC6有了很大的變化，一些編譯參數(shù)和鏈接參數(shù)被廢棄（比如/map:line），有一些改變了名稱,還有新增的選項(xiàng)，不過不用擔(dān)心，升級(jí)過程會(huì)自動(dòng)對其進(jìn)行轉(zhuǎn)換，最

8、終都會(huì)得到一個(gè)正確的解決方案和VC項(xiàng)目文件，這個(gè)過程不會(huì)遇到太多的麻煩，問題都出在隨后的編譯過程中，下面就將我在移植的過程中遇到的問題和我的解決方法總結(jié)一下，希望對還在用VC6維護(hù)代碼的朋友有所幫助。 一、_WIN32_WINNT 與 _WIN32_IE 設(shè)置沖突_WIN32_WINNT 與 _WIN32_IE設(shè)置不兼容會(huì)導(dǎo)致如下C1189致命錯(cuò)誤：StdAfx.cppc:program filesmicrosoft sdkswindowsv6.0aincludesdkddkver.h(217) : fatal error C1189: #error : _WIN32_WINNT settin

9、gs conflicts with _WIN32_IE settingStdAfx.cpp通常是項(xiàng)目中第一個(gè)編譯的文件，這個(gè)錯(cuò)誤將導(dǎo)致編譯無法繼續(xù)進(jìn)行。產(chǎn)生這個(gè)錯(cuò)誤的原因是原因是_WIN32_WINNT的版本定義太老，老的VC代碼對_WIN32_WINNT的典型設(shè)置是：#ifndef _WIN32_WINNT#define _WIN32_WINNT 0x0400#endif0x0400相對于VS2008所帶的Plarform SDK（在文件sdkddkver.h中）中_WIN32_IE的定義來說太老了，導(dǎo)致不兼容，可以將其改成0x0501或更高的版本避免這個(gè)問題，如下所示：#ifndef _W

10、IN32_WINNT#define _WIN32_WINNT 0x0501#endif也可以將這三行_WIN32_WINNT定義刪除，這樣就會(huì)使用Plarform SDK中的_WIN32_WINNT定義，自然就不存在不兼容問題了。不過出于對老版本VC的兼容考慮（畢竟以后可能還要使用VC6編譯代碼），最好這樣修改：#if _MSC_VER <= 1200 / MFC 6.0 or earlier#ifndef _WIN32_WINNT#define _WIN32_WINNT 0x0400#endif#endif二、afximpl.h文件中的語法錯(cuò)誤MFC出現(xiàn)的時(shí)候STL還沒有成為C+的標(biāo)準(zhǔn)

11、，所以MFC使用一套自己的模版庫，比如CArray、CList、CMap等等，這些類型聲明都在afximpl.h文件中。原來在VC6編譯器適用的模版語法可能不適用VC9，特別是當(dāng)以下四個(gè)環(huán)境變量設(shè)置不兼容時(shí)，就會(huì)出現(xiàn)這個(gè)編譯錯(cuò)誤，大致情況如下：e:softwaremicrosoft visual studio 9.0vcatlmfcsrcmfcafximpl.h(625) : error C2059: syntax error : '<L_TYPE_raw>'e:softwaremicrosoft visual studio 9.0vcatlmfcsrcmfcafx

12、impl.h(625) : error C2238: unexpected token(s) preceding ''e:softwaremicrosoft visual studio 9.0vcatlmfcsrcmfcafximpl.h(629) : error C2059: syntax error : '<L_TYPE_raw>'e:softwaremicrosoft visual studio 9.0vcatlmfcsrcmfcafximpl.h(629) : error C2238: unexpected token(s) precedin

13、g ''合理調(diào)整stdafx.h中WINVER、_WIN32_WINNT、_WIN32_WINDOWS和_WIN32_IE的設(shè)置可以避免這個(gè)問題，將三個(gè)與Windows版本有關(guān)的環(huán)境變量設(shè)置為0x0501或更高版本，將IE版本的環(huán)境變量設(shè)置為0x0500以后的版本就可以解決這個(gè)問題。當(dāng)然，考慮到與舊的VC6代碼兼容，可以采用上一個(gè)問題中提到的最后一個(gè)解決辦法，用_MSC_VER進(jìn)行隔離。三、 舊的CRT庫和新的安全CRT庫引起的C4996告警解決了環(huán)境變量設(shè)置不匹配導(dǎo)致的問題后，編譯過程就真正開始了，不過首先映入眼簾的應(yīng)該是成堆的C4996編譯告警，對每個(gè)使用了含字符串參數(shù)的C

14、RT庫函數(shù)都會(huì)有C4996編譯告警，一個(gè)典型的輸出如下所示：f:monfunc.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:softwaremicrosoft visual studio 9.0vcincludestri

15、ng.h(74) : see declaration of 'strcpy'MSDN online 是這樣解釋的：為了顯著增加CRT庫的安全性，許多CRT函數(shù)都有了一個(gè)更安全的新版本，新版本和舊版本的區(qū)別就是新版本函數(shù)名多了一個(gè)_s后綴。只要一個(gè)CRT函數(shù)有新的安全版本，編譯器就會(huì)產(chǎn)生一個(gè)C4996告警，不過，出現(xiàn)這個(gè)告警的目的并不是說舊版本的CRT函數(shù)將淡出CRT庫，告警出現(xiàn)只是為了提醒程序員這個(gè)函數(shù)有更安全的版本存在。一種安全的或者是被鼓勵(lì)的做法是用安全版本的函數(shù)替換現(xiàn)有的CRT函數(shù)，不過對于一個(gè)有相當(dāng)代碼量的項(xiàng)目，替換工作量也是巨大的，這可不是用名稱查找、替換就能簡單解決

16、的問題，因?yàn)樵S多安全版本的CRT函數(shù)參數(shù)個(gè)數(shù)也發(fā)生了變化。也可以用預(yù)處理指令消除這個(gè)告警：#pragma warning( disable : 4996 )或者定義 _CRT_SECURE_NO_WARNINGS 壓制這個(gè)告警（在stdafx.h中define或在項(xiàng)目屬性中設(shè)置預(yù)處理符號(hào),PreProcessor Definitions）。除了C語言的CRT函數(shù)外，POSIX 兼容函數(shù)也存在這個(gè)告警，解決方法是用POSIX標(biāo)準(zhǔn)名稱替換（比如access換成_access）或者是定義 _CRT_NONSTDC_NO_WARNINGS 壓制這個(gè)告警（方法同上）。四、“CWinApp:Enable3

17、dControls”引起的C4996告警這個(gè)是編譯使用了老的向?qū)傻腗FC代碼時(shí)遇到的問題，一個(gè)典型的告警信息輸出如下所示：Crpf:project.crp(52) : warning C4996: 'CWinApp:Enable3dControls': CWinApp:Enable3dControls is no longer needed. You should remove this call.e:softwaremicrosoft visual studio 9.0vcatlmfcincludeafxwin.h(4818) : see declaration of &

18、#39;CWinApp:Enable3dControls'通常向?qū)傻拇a是：#ifdef _AFXDLLEnable3dControls(); / Call this when using MFC in a shared DLL#elseEnable3dControlsStatic(); / Call this when linking to MFC statically#endif這兩個(gè)函數(shù)的調(diào)用是舊的MFC版本對新版本的操作系統(tǒng)特性的支持，在新的（那個(gè)時(shí)候是新的）Windows 95平臺(tái)上要這樣調(diào)用一下才能使用新的Windows 3D樣式的控件，否則就是老的Win 3.2樣子的

19、控件。想當(dāng)初喜歡OWL就是因?yàn)楦杏X它的控件比較“酷”，比如那個(gè)帶底紋的對話框，菱形的checkbox，還有帶圖標(biāo)的“OK”按鈕，看到MFC作出來的灰灰的界面就覺得土，不過后來就知道MFC做界面也是很漂亮的，比如我做的。，再打住。對于新的MFC版本來說已經(jīng)不需要再調(diào)用這兩個(gè)函數(shù)了，參考前面的方法，用_MSC_VER對其隔離就行了：#if _MSC_VER <= 1200 / MFC 6.0 or earlier#ifdef _AFXDLLEnable3dControls(); / Call this when using MFC in a shared DLL#elseEnable3dCo

20、ntrolsStatic(); / Call this when linking to MFC statically#endif#endif五、.def文件引起的連接告警對于普通的DLL項(xiàng)目中使用的.def文件通常會(huì)引起LNK4017鏈接告警，如下所示：.ComFunc.def(4) : warning LNK4017: DESCRIPTION statement not supported for the target platform; ignoredCreating library .Debug/ComFunc.lib and object .Debug/ComFunc.exp一個(gè)典型的

21、.def文件通常有以下內(nèi)容：LIBRARY "XorCryptor"DESCRIPTION 'XorCryptor Windows Dynamic Link Library'EXPORTS; Explicit exports can go here.消除這個(gè)連接告警的方法就是從.def文件中刪除DESCRIPTION描述信息，不過這個(gè)告警也不是什么大問題，不刪也可以。另一個(gè)可能產(chǎn)生的連接告警是LNK4222，通常出現(xiàn)在ocx控件和com組件的項(xiàng)目中，一個(gè)典型輸出是：Linking.PlusInModule.def : warning LNK4222: exp

22、orted symbol 'DllCanUnloadNow' should not be assigned an ordinal.PlusInModule.def : warning LNK4222: exported symbol 'DllGetClassObject' should not be assigned an ordinal.PlusInModule.def : warning LNK4222: exported symbol 'DllRegisterServer' should not be assigned an ordinal

23、.PlusInModule.def : warning LNK4222: exported symbol 'DllUnregisterServer' should not be assigned an ordinal出現(xiàn)這個(gè)告警的原因是舊的項(xiàng)目的.def文件通常這樣定義ocx和com必需的四個(gè)導(dǎo)出函數(shù)：EXPORTSDllCanUnloadNow 1 PRIVATEDllGetClassObject 2 PRIVATEDllRegisterServer 3 PRIVATEDllUnregisterServer 4 PRIVATE其中為這四個(gè)重要的導(dǎo)出函數(shù)指定了四個(gè)順序號(hào)。Win

24、dows平臺(tái)上通常用兩種方式定位DLL文件中的導(dǎo)出函數(shù)，一種是根據(jù)導(dǎo)出函數(shù)名稱，一種是根據(jù)順序號(hào)，上學(xué)時(shí)曾經(jīng)寫過一個(gè)顯示圖片的程序，能處理大多數(shù)當(dāng)時(shí)流行的圖像格式文件，唯獨(dú)jpeg格式的搞不定，有一次看到一個(gè)圖像處理軟件中包含了一個(gè)LoadJpeg.dll，很顯然這個(gè)DLL是處理jpeg格式的圖像文件的嘛，于是趕快用depends look了一下，頓時(shí)高喊：鬼啊。原來這個(gè)depends竟然查不到導(dǎo)出函數(shù)的名字，后來才知道還有NONAME參數(shù)強(qiáng)制用順序號(hào)定位導(dǎo)出函數(shù)，于是就常常弄個(gè)沒有導(dǎo)出函數(shù)名字的DLL到處show。嗯，又扯遠(yuǎn)了。話說為什么舊的系統(tǒng)要以此指定這四個(gè)導(dǎo)出函數(shù)的順序號(hào)我就沒有研究了

25、，反正現(xiàn)在不需要指定了，只要將1，2之類的刪除就行了，不過不刪好像也沒什么問題，它們會(huì)被自動(dòng)忽略。六、使用MFC的消息映射宏引起的編譯錯(cuò)誤錯(cuò)誤現(xiàn)象之一：f:project.plusmaindlg.cpp(220) : error C2440: 'static_cast' : cannot convert from 'void (_thiscall CPlusMainDlg:* )(int,BOOL)' to 'LRESULT (_thiscall CWnd:* )(WPARAM,LPARAM)'None of the functions with

26、 this name in scope match the target type錯(cuò)誤現(xiàn)象之二：f:project.crp(87) : error C2440: 'static_cast' : cannot convert from 'LRESULT (_thiscall CCrp:* )(LPCTSTR,int)' to 'LRESULT (_thiscall CWnd:* )(WPARAM,LPARAM)'None of the functions with this name in scope match the target type以上

27、兩個(gè)編譯錯(cuò)誤產(chǎn)生是因?yàn)樾屡f版本的MFC 中對ON_MESSAGE消息映射宏定義不同引起的，先看看老版本的MFC的ON_MESSAGE消息宏定義：#define ON_MESSAGE(message, memberFxn) message, 0, 0, 0, AfxSig_lwl, (AFX_PMSG)(AFX_PMSGW)(LRESULT (AFX_MSG_CALL CWnd:*)(WPARAM, LPARAM)&memberFxn ,再看看新版本的ON_MESSAGE定義：#define ON_MESSAGE(message, memberFxn) message, 0, 0, 0,

28、 AfxSig_lwl, (AFX_PMSG)(AFX_PMSGW) (static_cast< LRESULT (AFX_MSG_CALL CWnd:*)(WPARAM, LPARAM) > (memberFxn) ,注意，函數(shù)類型沒有變化，都是：LRESULT (AFX_MSG_CALL CWnd:*)(WPARAM, LPARAM);類型的函數(shù)指針（CWnd以及派生類的類成員函數(shù)指針），區(qū)別之處是新的ON_MESSAGE宏使用C+的 static_cast 操作符代替了C類型的強(qiáng)制轉(zhuǎn)換。產(chǎn)生這兩個(gè)錯(cuò)誤其實(shí)是因?yàn)橛脩魶]有按照ON_MESSAGE宏的約定聲明和定義消息響應(yīng)函數(shù)造成

29、的，比如，對于某些不需要處理返回值的消息響應(yīng)函數(shù)，用戶通常這樣聲明和定義消息響應(yīng)函數(shù)：在頭文件中聲明：afx_msg void On(WPARAM wParam,LPARAM lParam);在源文件中實(shí)現(xiàn)：void CCrp(WPARAM wParam, LPARAM lParam).或者更過分一些，直接指定為實(shí)際參數(shù)類型:在頭文件中聲明：afx_msg void On(LPCTSTR lpszMessage, int nPercent);在源文件中實(shí)現(xiàn)：void CCrp(LPCTSTR lpszMessage, int nPercent).舊版本的ON_MESSAGE使用了C類型的強(qiáng)制轉(zhuǎn)

30、換，宏解開后的代碼后不會(huì)產(chǎn)生錯(cuò)誤信息，但是改成對類型檢查很嚴(yán)格的static_cast 操作符時(shí)就出問題了，因?yàn)橥ú贿^static_cast 操作符的檢查。解決方法就是修改代碼，同時(shí)吸取教訓(xùn)，普遍使用的方法并不一定就能約定俗成，一切還是要按照規(guī)矩來。錯(cuò)誤現(xiàn)象之三：f:project.WzButton.cpp(74) : error C2440: 'static_cast' : cannot convert from 'UINT (_thiscall CWzButton:* )(CPoint)' to 'LRESULT (_thiscall CWnd:*

31、)(CPoint)'Cast from base to derived requires dynamic_cast or static_cast出現(xiàn)這個(gè)錯(cuò)誤的原因可是“人力不可抗拒”之原因造成的，因?yàn)榕f版本的 ON_WM_NCHITTEST 宏使用了UINT (_thiscall CWzButton:* )(CPoint);類型的類成員函數(shù)指針，其定義如下：#define ON_WM_NCHITTEST() WM_NCHITTEST, 0, 0, 0, AfxSig_wp, (AFX_PMSG)(AFX_PMSGW)(UINT (AFX_MSG_CALL CWnd:*)(CPoint)

32、&OnNcHitTest ,但是新版本變成了：#define ON_WM_NCHITTEST() WM_NCHITTEST, 0, 0, 0, AfxSig_l_p, (AFX_PMSG)(AFX_PMSGW) (static_cast< LRESULT (AFX_MSG_CALL CWnd:*)(CPoint) > (&ThisClass : OnNcHitTest) ,注意返回值類型由UINT改成了LRESULT，再加上static_cast的嚴(yán)格檢查，所以就出錯(cuò)了。修改的方法就是將你的OnNcHitTest函數(shù)由：afx_msg UINT OnNcHitTes

33、t(CPoint point);改成：afx_msg LRESULT OnNcHitTest(CPoint point);不必太在意，這個(gè)不是你的錯(cuò)，不過，如果你要維護(hù)一個(gè)老的界面庫（通常很多控件的subclass都會(huì)用到ON_WM_NCHITTEST），改起來還是很痛苦地，不扯了，繼續(xù)下一個(gè)。七、statreg.cpp 和 atlimpl.cpp 的廢棄（obsolete）問題在編譯老的ATL向?qū)傻拇a時(shí)，會(huì)遇到下面的編譯輸出：StdAfx.cppstatreg.cpp is obsolete. Please remove it from your project.atlimpl.cpp

34、 is obsolete. Please remove it from your project.因?yàn)槔系腁TL向?qū)傻拇a通常在stdafx.cpp文件中添加以下代碼：#ifdef _ATL_STATIC_REGISTRY#include <statreg.h>#include <statreg.cpp>#endif#include <atlimpl.cpp>根據(jù)提示刪除#include <statreg.cpp>和#include <atlimpl.cpp>兩行代碼就行了，不過更好的辦法是這樣改：#ifdef _ATL_STAT

35、IC_REGISTRY#include <statreg.h>#if _MSC_VER <= 1200 / MFC 6.0 or earlier#include <statreg.cpp>#endif#endif#if _MSC_VER <= 1200 / MFC 6.0 or earlier#include <atlimpl.cpp>#endif八、新的C+編譯器不再支持默認(rèn)類型的變量定義錯(cuò)誤現(xiàn)象是：f:project.WzCheckBox.cpp(464) : error C4430: missing type specifier - int

36、 assumed. Note: C+ does not support default-int產(chǎn)生這個(gè)錯(cuò)誤的原因是程序中出現(xiàn)了這樣的代碼：const some_const_var = 10;或static some_static_bool = FALSE;新的C+編譯器嚴(yán)格按照C+標(biāo)準(zhǔn)，不再支持默認(rèn)類型的變量定義方式，必須嚴(yán)格指定變量類型，如下使用：const int some_const_var = 10;或static BOOL some_static_bool = FALSE;九、for 語句的變量作用域問題考察下面的代碼：for(int i = 0; i < 120; i+)if

37、(something_happen)break;.if(i < 120)/something happen在VC6的編譯器中，這樣的代碼是沒有問題的，因?yàn)閂C6的編譯器為了兼容舊的Microsoft C/C+編譯器，沒有嚴(yán)格按照C+標(biāo)準(zhǔn)執(zhí)行，但是從VC7開始，VC的編譯器開始遵守C+標(biāo)準(zhǔn)，所以就會(huì)出現(xiàn)“變量i沒有定義的錯(cuò)誤”。解決的方法也很簡單，按照J(rèn)im Hyslop 和 Herb Sutter的經(jīng)典對話系列的第四篇中的方法，改成如下就可以了：int i;for(i = 0; i < 120; i+)十、字符串函數(shù)的返回值問題strchr(_tcschr)、strpbrk(_tc

38、spbrk ?)、strrchr(_tcsrchr)和strstr(_tcsstr)這四個(gè)函數(shù)在VC6的CRT庫中定義的返回值都是char *(TCHAR *)，所以以前的代碼通常是這樣使用的：TCHAR *cp = _tcschr( pszPath, _T('') );/使用*cp，可以通過cp指針修改pszPath的內(nèi)容這其實(shí)是一個(gè)“漏洞”，因?yàn)槿绻鹥szPath是const char(TCHAR) *字符串，那么就表示它不希望修改字符串的內(nèi)容，但是調(diào)用strchr(_tcschr)函數(shù)后就可以通過cp指針修改其內(nèi)容了，這豈不荒謬？所有在新版本的CRT庫中，這幾個(gè)函數(shù)的返回

39、值都改成const char *，這就會(huì)導(dǎo)致上面的代碼產(chǎn)生編譯錯(cuò)誤。建議的修改方式是改成如下方式：const TCHAR *cp = _tcschr( pszPath, _T('') );/不能再通過cp指針修改pszPath的內(nèi)容但是這樣修改可能對代碼的影響比較大，比如下面的代碼：TCHAR buf256; /局部緩沖區(qū).TCHAR *cp = _tcschr( buf, _T('') );/作為局部緩沖區(qū)（非const），希望通過cp修改buf的內(nèi)容這種情況怎么辦呢？對了，C+還有個(gè)const_cast操作符，這時(shí)就可以排上用場了：TCHAR *cp = c

40、onst_char<TCHAR *>(_tcschr( buf, _T('') );不過上面的方法要慎用，除非確定buf是非const的，否則最好老老實(shí)實(shí)地修改代碼。十一、類成員函數(shù)指針做為函數(shù)參數(shù)的“C3867”錯(cuò)誤考察下面的代碼，CWzWindowsHook類的構(gòu)造函數(shù)使用一個(gè)該類的成員函數(shù)指針，這樣構(gòu)造對象時(shí)可以選擇消息過濾的handler，可以是MouseMsgFilter，也可以是KeyboardMsgFilter：typedef BOOL (CWzWindowsHook:*FILTERPROC)(WPARAM wParam, LPARAM lParam)

41、;/ A hook used in customization sheet to filter keyboard/mouse eventsclass CWzWindowsHookprivate:FILTERPROC m_pFilter;BOOL MouseMsgFilter(WPARAM wParam, LPARAM lParam);BOOL KeyboardMsgFilter(WPARAM wParam, LPARAM lParam);public:CWzWindowsHook(FILTERPROC pFilter) : m_pFilter(pFilter)舊的遺留代碼存在這樣的用法：CWz

42、WindowsHook mouseHooker(CWzWindowsHook:MouseMsgFilter);在VC6的編譯器下編譯可能沒有問題，但是在VC9的編譯器下編譯會(huì)有如下報(bào)錯(cuò)：f:project.WzWindowsHook.cpp(272) : error C3867: 'CWzWindowsHook:MouseMsgFilter': function call missing argument list; use '&CWzWindowsHook:MouseMsgFilter' to create a pointer to member雖然C

43、+從C繼承來了函數(shù)名即是函數(shù)地址的語法規(guī)則，但是根據(jù)C+的標(biāo)準(zhǔn)，類成員函數(shù)的指針仍然需要一個(gè)取地址符“&”。解決方法很簡單，按照提示改成如下代碼即可：CWzWindowsHook mouseHooker(&CWzWindowsHook:MouseMsgFilter);十二、wchar_t *類型與USHORT *的轉(zhuǎn)換錯(cuò)誤VC6的編譯器不支持wchar_t數(shù)據(jù)類型，wchar_t實(shí)際上被定義成unsigned short，VC9的編譯器已經(jīng)支持wchar_t為內(nèi)置數(shù)據(jù)類型，但是由一個(gè)編譯選項(xiàng)控制，這個(gè)選項(xiàng)默認(rèn)是打開的，也就是將wchar_t作為編譯器的內(nèi)置數(shù)據(jù)類型。但是OLEC

44、HAR和WCHAR的定義仍然是unsigned short，在VC6的編譯環(huán)境中，兩者的指針都是USHORT *，相互賦值和做為函數(shù)參數(shù)傳遞沒有問題，但是如果wchar_t作為編譯器的內(nèi)置數(shù)據(jù)類型，那就意味著wchar_t *與OLECHAR *或WCHAR *是兩種不同類型的指針，相互賦值就會(huì)報(bào)編譯錯(cuò)誤，下面的信息就是一個(gè)典型的錯(cuò)誤輸出：f:project.shellpidl.cpp(290) : error C2664: 'MultiByteToWideChar' : cannot convert parameter 5 from 'USHORT *' to

45、 'LPWSTR'Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast解決的方法就是使用C+的reinterpret_cast操作符或使用C-style強(qiáng)制轉(zhuǎn)換，當(dāng)然也可以在項(xiàng)目屬性設(shè)置中關(guān)閉前面提到的那個(gè)選項(xiàng)（這個(gè)偶美試過，不知道會(huì)不會(huì)有其它問題）。- VC6到VS2010中的轉(zhuǎn)換1、 error C2668: 'sqrt' : ambiguous call to overloaded function

46、在VS2005中存在sqrt函數(shù)的重載。當(dāng)編譯器看到sqrt(int)時(shí)，找不到相應(yīng)的函數(shù)，此時(shí)存在sqrt(float)和sqrt(long double)兩個(gè)函數(shù)，編譯器不知道程序員需要哪個(gè)函數(shù)，就會(huì)出現(xiàn)錯(cuò)誤。可以使用sqrtf( )代替。2、 error C2039: 'ReadHuge' : is not a member of 'CFileVS2005中，readhuge被read包括了。3、 error C2668: 'pow' : ambiguous call to overloaded function在VS2005中，需要寫成pow(

47、(double)i, 2)，原因我沒有查到。其函數(shù)原型為 double _cdecl pow(_in double _X, _in double _Y); 在VC6中，函數(shù)原型為 _CRTIMP double _cdecl pow (double, double);4. 以前可以這樣用try catchcatch(CException *e)pApp->Warn("%s",e->GetErrorMessage);e->Delete();return FALSE;現(xiàn)在必須修改為：catch(CException *e)TCHAR errormsg255;e-

48、>GetErrorMessage (errormsg,255,NULL);pApp->Warn("%s",errormsg);e->Delete();return FALSE;5. strchr必須強(qiáng)制轉(zhuǎn)換一下。以前可以 char *str2=strchr(line,'|');2005必須 char *str2=(char *)strchr(line,'|');6. lifescope of int i in for(int i; i< size; +i)in VC6,the codes below are okfor

49、(int i = 0; i< 10; +i)/.for(i = 20; i< 40;+i)/.but in VS2005, we should write like below:for(int i = 0; i< 10; +i)/.for(int i = 20; i< 40;+i)/.in fact, from , the compiler accord with C+ standard more than VC6.If you are porting a VC6 project to VS2005, you will encounter many many codes

50、 like this.7. ON_WM_NCHITTEST (and other MFC macros) won't compile in VS2005VS2005中，ON_WM_NCHITTEST宏編譯不過When I add a message handler of ON_WM_NCHITTEST to a CControlbar-derived class, it compiles error:error C2440: 'static_cast' : cannot convert from 'UINT (_thiscall CMenuBar:* )(CPo

51、int)' to 'LRESULT (_thiscall CWnd:* )(CPoint)' Cast from base to derived requires dynamic_cast or static_castTo fix this bug, we should change the prototype of OnNcHitTestfromafx_msg UINT OnNcHitTest(CPoint point);toafx_msg LRESULT OnNcHitTest(CPoint point);8. VS2005中有些可能引起內(nèi)存越界的函數(shù)不建議使用了I

52、n VS2005, some dangerous functions are deprecatedchar c10;strcpy(c, "testtestts"); /ok with VC6, but not in VS2005strcpy_s(c, _countof(c),"testtestt");/9 chars, ok in VS2005strcpy_s(c, _countof(c),"testtestt");/10 chars, assert! in VS20059.error C2440: 'static_cast&

53、#39; : cannot convert from 'HRESULT (_thiscall CtestpalView:* )(WPARAM,LPARAM)' to 'AFX_PMSG'None of the functions with this name in scope match the target typeHRESULT (_thiscall CtestpalView:* )(WPARAM,LPARAM)AFX_PMSG類型：void (AFX_MSG_CALL CCmdTarget:* )(void)10. error C2440: 'st

54、atic_cast' : cannot convert from 'void (_thiscall CSettingStart:* )(BOOL,HANDLE)' to 'void (_thiscall CWnd:* )(BOOL,DWORD)'In VC6, the handler for ON_WM_ACTIVATEAPP was expected to beafx_msg void OnActivateApp( BOOL, HANDLE);In VC7 and vs2005, it has been changed toafx_msg void O

55、nActivateApp( BOOL, DWORD );11.error LNK2019: unresolved external symbol "wchar_t * _stdcall _com_util:Co.解決方法，Property page ->C/C+ ->Language ->treat Wchar-t 改為 Noa. ON_MESSAGE(message,OnMyMessage);OnMyMessage返回值必須為LRESULT，其形式為：afx_msg LRESULT OnMyMessage(WPARAM, LPARAM)；如果不符合，則有錯(cuò)誤提示：

56、error C2440: “static_cast”: 無法從“void (_thiscall CPppView:* )(WPARAM,LPARAM)”轉(zhuǎn)換為“LRESULT (_thiscall CWnd:* )(WPARAM,LPARAM)”在匹配目標(biāo)類型的范圍內(nèi)沒有具有該名稱的函數(shù)error C2440: “static_cast”: 無法從“void (_thiscall CPppView:* )(void)”轉(zhuǎn)換為“LRESULT (_thiscall CWnd:* )(WPARAM,LPARAM)”在匹配目標(biāo)類型的范圍內(nèi)沒有具有該名稱的函數(shù)b. ON_COMMAND_EX(id,OnMyMessage2);在VS2005中，OnMyMessage返回值必須為BOOL，且含有一個(gè) UINT 參數(shù)指出了命令I(lǐng)D，其形式為：afx_msg BOOL OnMyMessage(UINT)；如果不符合，則有錯(cuò)誤提示，如在VS6中，OnMyMessage2的定義為afx_msg BOOL OnViewZoomBar()時(shí)亦可正常編譯通過，但在VS2005下，有錯(cuò)誤提示：error C2440: