- 主题:奇怪的问题,VC60和VS2022的MFC库不一样?
char* nurl="mmmmmmmmm";
CString rs=nurl;
其中的第二行代码,
在VC60是完全没问题的,编译无警告无错误,结果正确,无论多字节还是unicode字节,都是如此。单步调试发现是进入了CString类的构造函数CString::CString(LPCTSTR lpsz)
可是在VS2022,这段代码是编译不通过的,提示无法类型转换,提示找不到构造函数
难道VC60和VS2022的MFC库不一样?
--
FROM 13.215.209.*
nurl要用const吧,不然vs2022报错,说你有修改常量字符串的风险。
剩下就轻松编译过了,不管是ATL里的CString,还是MFC里的CString
const char* nurl = "mmmmmmmmm";
CString rs = nurl;
最简单的:
const auto nurl = "mmmmmmmmm";
--
修改:z16166 FROM 114.240.244.*
FROM 114.240.244.*
你试过没?这问题没那么简单。
我以前一直喜欢用char * 直接赋值给CString 变量,CString 会自动做转换,很方便。
比如 typeid('a').name()的返回值永远是char*类型的,以前可以直接初始化给CString 变量。
可是VS2022不可以这么做了。
char *d;
CString a=d; //VS2022常规情况下会出错(编译器进行特殊复杂难懂的设置后也可以通过),而vc60可以这么搞毫无问题
CString a(d);//可以
CString a;a=d;//可以
CString a=(CString)d;//可以
那个错误信息是:
严重性代码说明项目文件行禁止显示状态
错误(活动)E0415不存在从 "char *" 转换到 "ATL::CStringT<wchar_t, StrTraitMFC_DLL<wchar_t, ATL::ChTraitsCRT<wchar_t>>>" 的适当构造函数Project1F:\t2\Project1\Project1.cpp39
【 在 z16166 的大作中提到: 】
: nurl要用const吧,不然vs2022报错,说你有修改常量字符串的风险。
: 剩下就轻松编译过了,不管是ATL里的CString,还是MFC里的CString
: const char* nurl = "mmmmmmmmm";
: ...................
--
修改:bn95 FROM 111.48.114.*
FROM 111.48.114.*
我用atlstr.h测试的
用afxstr.h的话,是因为有个宏_ATL_CSTRING_EXPLICIT_CONSTRUCTORS控制了CtringT的部分构造函数为explicit的,即CSTRING_EXPLICIT。
解决也简单,删掉MFC project wizard生成的framework.h里的这个宏定义就完事了
#define _ATL_CSTRING_EXPLICIT_CONSTRUCTORS // some CString constructors will be explicit
CSTRING_EXPLICIT CStringT(_In_opt_z_ const YCHAR* pszSrc) :
CThisSimpleString( StringTraits::GetDefaultManager() )
{
if( !CheckImplicitLoad( pszSrc ) )
{
*this = pszSrc;
}
}
【 在 bn95 的大作中提到: 】
: 你试过没?这问题没那么简单。
: 我以前一直喜欢用char * 直接赋值给CString 变量,CString 会自动做转换,很方便。
: 比如 typeid('a').name()的返回值永远是char*类型的,以前可以直接初始化给CString 变量。
: ...................
--
修改:z16166 FROM 114.240.244.*
FROM 114.240.244.*
厉害啊
【 在 z16166 的大作中提到: 】
: 我用atlstr.h测试的
: 用afxstr.h的话,是因为有个宏_ATL_CSTRING_EXPLICIT_CONSTRUCTORS控制了CtringT的部分构造函数为explicit的,即CSTRING_EXPLICIT。
: 解决也简单,删掉MFC project wizard生成的framework.h里的这个宏定义就完事了
: ...................
--
FROM 111.48.114.*
vc6的CString构造函数既有接受char*,也有接受wchar_t*的,vs2022估计只有接受后者的了
【 在 bn95 的大作中提到: 】
: char* nurl="mmmmmmmmm";
: CString rs=nurl;
:
: 其中的第二行代码,
: 在VC60是完全没问题的,编译无警告无错误,结果正确,无论多字节还是unicode字节,都是如此。单步调试发现是进入了CString类的构造函数CString::CS
: ..................
发自「今日水木 on iPhone 6s Plus」
--
FROM 39.149.40.*
你有没有注意到这里的wchar?
【 在 bn95 的大作中提到: 】
:
: 你试过没?这问题没那么简单。
:
: 我以前一直喜欢用char * 直接赋值给CString 变量,CString 会自动做转换,很方便。
: 比如 typeid('a').name()的返回值永远是char*类型的,以前可以直接初始化给CString 变量。
--
FROM 219.76.163.*
厉害,佩服。
【 在 z16166 的大作中提到: 】
: 我用atlstr.h测试的
: 用afxstr.h的话,是因为有个宏_ATL_CSTRING_EXPLICIT_CONSTRUCTORS控制了CtringT的部分构造函数为explicit的,即CSTRING_EXPLICIT。
: 解决也简单,删掉MFC project wizard生成的framework.h里的这个宏定义就完事了
: ...................
--
FROM 136.56.37.*
【 在 bn95 的大作中提到: 】
: char* nurl="mmmmmmmmm";
: CString rs=nurl;
: 其中的第二行代码,
: ...................
这个很正常把, VC6的c++太古老了, 和后来的C++标准, 后面的出来的操作系统有冲突,
VC后来的标准库和MFC经历重写是必然的, 另外, 为了代码的健壮和安全,
对以前容忍的用法,变成error也是必要的。
--
FROM 124.126.3.*