vs2008使用点滴
vs2008使用点滴
2011年02月15日
1.
vs2008中vc++中strcpy最近用vs2008新建了一个项目，直接将代码copy过来，居然报错： error C2664: 'strcpy' : cannot convert parameter 1 from 'WCHAR [128]' to 'char *' 百思不得其解，后来搜索发现： vs2008默认是unicode编码的，unicode编码的字符串每个字符两个字节的，不能简单的"info",要用TEXT()宏转换下。到项目属性－>配置属性－》c/c++－》命令行可以看到有 /D "_UNICODE" /D "UNICODE" 说明是unicode编码的，VS2003.2005都没这个命令的，所以就VS2008报错原来如此啊，于是有网友建议使用：wcscpy 结果还是报错，最后改为：lstrcpy((LPWSTR)nd.szTip,TEXT("中国")); //或用(LPWSTR)对变量强制转化亦可。通过了编译，一切正常。
2.
vs2008下编译c程序出现 0x67486af2 (msvcr90d.dll) 处未处理的异常: 0xC0000005: 写入位置 0x00000000 时发生访问冲突
[ 标签：vs2008,0xc0000005,0x00000000 ]
RT，在vs2008下x写C程序，编译通过的，就是出现错误提示如下
0x67486af2 (msvcr90d.dll) 处未处理的异常: 0xC0000005: 写入位置 0x00000000 时发生访问冲突
用的是64位的win7 不知道是不是跟系统有关系
添加一个64位调试配置
1. 打开一个已存在的32位工程(例如, MyApplication).
2. 在”Build”菜单上, 点击”Configuration Manager”.
3. 在”Active Solution Configurations”列表中, 点击”New”.
4. 在”New Solution Configurations”对话框中, 在”Solution Configuration Name”下面选择”Debug64”(不包含引号), 并且在”Copy Settings From”下面选择”Debug”.
5. 点击”OK”.
6. 在”Configuration Manager”对话框中, 在”Active Solution Configuration”列表中, 点击选择”Debug64”, 然后点击”OK”.
修改编译器和链接器设置
由于64位的编译器和链接器的参数配置和32位的有些不一样, 我们需要修改部分选项, 下面是这些配置步骤:
1. 在”Solution”(中文:解决方案)浏览窗口中, 右键”Project”, 然后, 点击”Properties”.
2. 在”C/C++”节点, 选择”General”. 设置”Debug Information Format”到”Program Database”(对应的编译选项是/Zi).
3. 在”C/C++”节点中, 选择”Code generation”. 设置”Buffer Security Check”到”No”(对应的编译选项是/GS).
4. 在”Linker”节点, 选择”Command Line”.在”Additional Options”下面, 添加”/MACHINE:IA64”(没有引号).
5. 如果你的应用程序是基于MFC的,你必须添加MFC路径以避免收到链接错误:LNK1104 on the Mfc42d.lib file.
添加MFC路径, 按下面步骤:
a. 在”Tools”菜单上, 点击”Options”.
b. 在”Projects”下面, 选择”VC++ Directories”. 在”Show directories”列表中, 选择”Library Files”.如果库路径没有列出, 添加这个库路径"\Microsoft SDK\lib\IA64\mfc"(没有引号).
注意:如果MyApplication是一个MFC应用程序并且这个工程用到了MFC相关的.dll文件, 请确信在IA64计算机上, 那些.dll文件从\Microsoft SDK\NoRedist\Win64文件夹中已被拷贝到\System32文件夹中.
这些dll文件是:
Mfc42d.dll
Mfco42d.dll
Msvcrtd.dll
完成这些后, 就可以build 64位可执行程序了.
一般是内存越界访问或变量没有初始化就开始使用造成的。
7.
strcpy是C运行时函数,是标准C提供的函数
lstrcpy是Windows API
而StrCpy仅仅是lstrcpy的调用而已,相当于lstrcpy
在微软的开发环境里比方说VC开发windows程序，最好使用lstrcpy()，否则很多地方会出问题，用了lstrcpy()就放心多了
如果定义了 unicode
lstrcpy() 和 wstrcpy()功能相同
否则 和 strcpy()功能相同
补充一下
lstrcpy是api，任何可以调用api的语言都能使用。
8.VC++6.0下的工程在VS2008中打开注意事项
VC9的编译器相对于VC6有了很大的变化，一些编译参数和链接参数被废弃（比如/map:line），有一些改变了名称,还有新增的选项，不过不用担心，升级过程会自动对其进行转换，最终都会得到一个正确的解决方案和VC项目文件，这个过程不会遇到太多的麻烦，问题都出在随后的编译过程中，下面就将我在移植的过程中遇到的问题和我的解决方法总结一下，希望对还在用VC6维护代码的朋友有所帮助。
一、_WIN32_WINNT 与 _WIN32_IE 设置冲突
_WIN32_WINNT 与 _WIN32_IE设置不兼容会导致如下C1189致命错误：
StdAfx.cpp
c:\program files\microsoft sdks\windows\v6.0a\include\sdkddkver.h(217) : fatal error C1189: #error : _WIN32_WINNT settings conflicts with _WIN32_IE setting
StdAfx.cpp通常是项目中第一个编译的文件，这个错误将导致编译无法继续进行。产生这个错误的原因是原因是_WIN32_WINNT的版本定义太老，老的VC代码对_WIN32_WINNT的典型设置是：
#ifndef _WIN32_WINNT
#define _WIN32_WINNT 0x0400
#endif
0x0400相对于VS2008所带的Plarform SDK（在文件sdkddkver.h中）中_WIN32_IE的定义来说太老了，导致不兼容，可以将其改成0x0501或更高的版本避免这个问题，如下所示：
#ifndef _WIN32_WINNT
#define _WIN32_WINNT 0x0501
#endif
也可以将这三行_WIN32_WINNT定义删除，这样就会使用Plarform SDK中的_WIN32_WINNT定义，自然就不存在不兼容问题了。不过出于对老版本VC的兼容考虑（毕竟以后可能还要使用VC6编译代码），最好这样修改：
#if _MSC_VER '
e:\software\microsoft visual studio 9.0\vc\atlmfc\src\mfc\afximpl.h(625) : error C2238: unexpected token(s) preceding ';'
e:\software\microsoft visual studio 9.0\vc\atlmfc\src\mfc\afximpl.h(629) : error C2059: syntax error : ''
e:\software\microsoft visual studio 9.0\vc\atlmfc\src\mfc\afximpl.h(629) : error C2238: unexpected token(s) preceding ';'
合理调整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) : 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 压制这个告警（方法同上）。
四、“CWinApp::Enable3dControls”引起的C4996告警
这个是编译使用了老的向导生成的MFC代码时遇到的问题，一个典型的告警信息输出如下所示：
CrpFileCrack.cpp
f:\project\.....\crpfilecrack.cpp(52) : warning C4996: 'CWinApp::Enable3dControls': CWinApp::Enable3dControls is no longer needed. You should remove this call.
e:\software\microsoft visual studio 9.0\vc\atlmfc\include\afxwin.h(4818) : see declaration of 'CWinApp::Enable3dControls'
通常向导生成的代码是：
#ifdef _AFXDLL
Enable3dControls(); // Call this when using MFC in a shared DLL
#else
Enable3dControlsStatic(); // Call this when linking to MFC statically
#endif
这两个函数的调用是旧的MFC版本对新版本的操作系统特性的支持，在新的（那个时候是新的）Windows 95平台上要这样调用一下才能使用新的Windows 3D样式的控件，否则就是老的Win 3.2样子的控件。想当初喜欢OWL就是因为感觉它的控件比较“酷”，比如那个带底纹的对话框，菱形的checkbox，还有带图标的“OK”按钮，看到MFC作出来的灰灰的界面就觉得土，不过后来就知道MFC做界面也是很漂亮的，比如我做的。。。。，再打住。对于新的MFC版本来说已经不需要再调用这两个函数了，参考前面的方法，用_MSC_VER对其隔离就行了：
#if _MSC_VER Windows Dynamic Link Library'
EXPORTS
; Explicit exports can go here
..................
消除这个连接告警的方法就是从.def文件中删除DESCRIPTION描述信息，不过这个告警也不是什么大问题，不删也可以。另一个可能产生的连接告警是LNK4222，通常出现在ocx控件和com组件的项目中，一个典型输出是：
Linking...
.\PlusInModule.def : warning LNK4222: exported 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
.\PlusInModule.def : warning LNK4222: exported symbol 'DllUnregisterServer' should not be assigned an ordinal
出现这个告警的原因是旧的项目的.def文件通常这样定义ocx和com必需的四个导出函数：
EXPORTS
DllCanUnloadNow @1 PRIVATE
DllGetClassObject @2 PRIVATE
DllRegisterServer @3 PRIVATE
DllUnregisterServer @4 PRIVATE
其中为这四个重要的导出函数指定了四个顺序号。Windows平台上通常用两种方式定位DLL文件中的导出函数，一种是根据导出函数名称，一种是根据顺序号，上学时曾经写过一个显示图片的程序，能处理大多数当时流行的图像格式文件，唯独jpeg格式的搞不定，有一次看到一个图像处理软件中包含了一个LoadJpeg.dll，很显然这个DLL是处理jpeg格式的图像文件的嘛，于是赶快用depends look了一下，顿时高喊：鬼啊～～～。原来这个depends竟然查不到导出函数的名字，后来才知道还有NONAME参数强制用顺序号定位导出函数，于是就常常弄个没有导出函数名字的DLL到处show。。。。嗯，又扯远了。话说为什么旧的系统要以此指定这四个导出函数的顺序号我就没有研究了，反正现在不需要指定了，只要将@1，@2之类的删除就行了，不过不删好像也没什么问题，它们会被自动忽略。
六、使用MFC的消息映射宏引起的编译错误
错误现象之一：
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 this name in scope match the target type
错误现象之二：
f:\project\.....\crpfileopavdlg.cpp(87) : error C2440: 'static_cast' : cannot convert from 'LRESULT (__thiscall CCrpFileOpavDlg::* )(LPCTSTR,int)' to 'LRESULT (__thiscall CWnd::* )(WPARAM,LPARAM)'
None of the functions with this name in scope match the target type
以上两个编译错误产生是因为新旧版本的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, AfxSig_lwl, \
(AFX_PMSG)(AFX_PMSGW) \
(static_cast \
(memberFxn)) },
注意，函数类型没有变化，都是：
LRESULT (AFX_MSG_CALL CWnd::*)(WPARAM, LPARAM);
类型的函数指针（CWnd以及派生类的类成员函数指针），区别之处是新的ON_MESSAGE宏使用C++的 static_cast 操作符代替了C类型的强制转换。产生这两个错误其实是因为用户没有按照ON_MESSAGE宏的约定声明和定义消息响应函数造成的，比如，对于某些不需要处理返回值的消息响应函数，用户通常这样声明和定义消息响应函数：
在头文件中声明：
afx_msg void OnFileProcess(WPARAM wParam,LPARAM lParam);
在源文件中实现：
void CCrpFileOpavDlg::OnFileProcess(WPARAM wParam, LPARAM lParam)
{
.......
}
或者更过分一些，直接指定为实际参数类型:
在头文件中声明：
afx_msg void OnFileProcess(LPCTSTR lpszMessage, int nPercent);
在源文件中实现：
void CCrpFileOpavDlg::OnFileProcess(LPCTSTR lpszMessage, int nPercent)
{
.......
}
旧版本的ON_MESSAGE使用了C类型的强制转换，宏解开后的代码后不会产生错误信息，但是改成对类型检查很严格的static_cast 操作符时就出问题了，因为通不过static_cast 操作符的检查。解决方法就是修改代码，同时吸取教训，普遍使用的方法并不一定就能约定俗成，一切还是要按照规矩来。
错误现象之三：
f:\project\.....\WzButton.cpp(74) : error C2440: 'static_cast' : cannot convert from 'UINT (__thiscall CWzButton::* )(CPoint)' to 'LRESULT (__thiscall CWnd::* )(CPoint)'
Cast from base to derived requires dynamic_cast or static_cast
出现这个错误的原因可是“人力不可抗拒”之原因造成的，因为旧版本的 ON_WM_NCHITTEST 宏使用了
UINT (__thiscall CWzButton::* )(CPoint);
类型的类成员函数指针，其定义如下：
#define ON_WM_NCHITTEST() \
{ WM_NCHITTEST, 0, 0, 0, AfxSig_wp, \
(AFX_PMSG)(AFX_PMSGW)(UINT (AFX_MSG_CALL CWnd::*)(CPoint))&OnNcHitTest },
但是新版本变成了：
#define ON_WM_NCHITTEST() \
{ WM_NCHITTEST, 0, 0, 0, AfxSig_l_p, \
(AFX_PMSG)(AFX_PMSGW) \
(static_cast (&ThisClass :: OnNcHitTest)) },
注意返回值类型由UINT改成了LRESULT，再加上static_cast的严格检查，所以就出错了。修改的方法就是将你的OnNcHitTest函数由：
afx_msg UINT OnNcHitTest(CPoint point);
改成：
afx_msg LRESULT OnNcHitTest(CPoint point);
不必太在意，这个不是你的错，不过，如果你要维护一个老的界面库（通常很多控件的subclass都会用到ON_WM_NCHITTEST），改起来还是很痛苦地，不扯了，继续下一个。
七、statreg.cpp 和 atlimpl.cpp 的废弃（obsolete）问题
在编译老的ATL向导生成的代码时，会遇到下面的编译输出：
StdAfx.cpp
statreg.cpp is obsolete. Please remove it from your project.
atlimpl.cpp is obsolete. Please remove it from your project.
因为老的ATL向导生成的代码通常在stdafx.cpp文件中添加以下代码：
#ifdef _ATL_STATIC_REGISTRY
#include
#include
#endif
#include
根据提示删除#include 和#include 两行代码就行了，不过更好的办法是这样改：
#ifdef _ATL_STATIC_REGISTRY
#include
#if _MSC_VER
#endif
#endif
#if _MSC_VER
#endif
八、新的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;
九、for 语句的变量作用域问题
考察下面的代码：
for(int i = 0; i (_tcschr( buf, _T('\\') ));
不过上面的方法要慎用，除非确定buf是非const的，否则最好老老实实地修改代码。
十一、类成员函数指针做为函数参数的“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);
十二、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强制转换，当然也可以在项目属性设置中关闭前面提到的那个选项（这个偶美试过，不知道会不会有其它问题）。
