CString和const char*
(2011-04-07 20:15:23)
标签:
cstring和constcharit |
分类: 技术文章 |
void
COpenTestDlg::OnOpenImage()
{
// TODO: Add your control notification handler code here
CFile File=0;
CString FileName;
CString strResult;
CFileDialog dlg(TRUE,0,0,OFN_HIDEREADONLY," 位图文件|*.bmp|
所有文件|*.*||",this);
if (dlg.DoModal()==IDOK)
{
}
}
用int CBmp24b::OpenFile(const char *strFilename, CString
&str)函数打开图像的时候,因为我看它第一个参数定义成的const char
*,所以原来我直接定义const char
*FileName;也没注意GetPathName()函数返回的是CString类型的。编译没报错。但是运行的时候不显示图像,然后调试的时候发现OpenFile(FileName,
strResult)里提示打开图像失败。然后查了下资料,将FileName定义成CString类型了才可以了。感觉这些类型转换的好复杂,没头绪。
下面是网上找的一些资料。
CString是个好东西,有很多好用的成员函数,并且动态分配内存空间。但在MFC学习初期,容易把CString与const
char*,char*混淆。遇到三种类型数据转换时,总是得过且过。下面就剖析一下三者之间的转换关系与方法。
1、CString与const char*(LPCTSTR---是在Unicode环境下const char*的宏定义)
CString类提供一个const
char*()把CString类型转换为LPCTSTR类型。比如AfxMessageBox()的使用,可以采用:char
szMessageText[] = "Unknown error";
AfxMessageBox(szMessageText);也可以这样:CString strMessageText("Unknown
;error");
AfxMessageBox(strMessageText);
CString类也提供了一个构造函式把LPCTSTR类型转换为CString类型。比如:CString
strTruth;strTruth += " is alive";
2、CString与char*调用CString::GetBuffer在Buffer中开辟一定大小的空间并返回一个char*。注意要在使用完char*后要调用CString::ReleaseBuffer以此保证CString的动态性。例如:[pre]CString strTest("test");strncpy(strTest.GetBuffer(5), "T", 1);strTest.ReleaseBuffer();ASSERT(strTest == "Test");[/pre][pre]编写以字符串为参数的函数所遵循的规则:[/pre][pre]a、如果函数不改写字符串的内容并且要调用C Runtime的函数,那么函数要用const char*类型参数;[/pre][pre]b、如果函数不改写字符串的内容并且要调用CString的成员函数,那么函数要用const CString&类型参数;[/pre][pre]c、如果函数要改写字符串的内容,那么函数要用CString&类型参数。
关于CString剖析,“strcmp”: 不能将参数1从“CString”转换为“const char
*”问题
CString csNewListBoxText;
CString csOldListBoxText(g_csFirstListBoxSelText);
if(strcmp(csNewListBoxText,csOldListBoxText)!=0)
//Release版本下出错情况:
//error C2664: “strcmp”: 不能将参数1 ,2从“CString”转换为“const char *”
//于是改成下面的:在前面添加(char *)(LPCTSTR)。
if(strcmp((char *)(LPCTSTR)csNewListBoxText,(char
*)(LPCTSTR)csOldListBoxText)!=0)
//没错
网上资料:
CString剖析
CString类功能强大,比STL的string类有过之无不及.新手使用CString时,都会被它强大
的功能所吸引.然而由于对它内部机制的不了解,新手在将CString向C的字符数组转换时
容易出现很多问题.因为CString已经重载了LPCTSTR运算符,所以CString类向const
char *转换时没有什么麻烦,如下所示:
char a[100];
CString str("aaaaaa");
strncpy(a,(LPCTSTR)str,sizeof(a));
//或者如下:
strncpy(a,str,sizeof(a));
以上两种用法都是正确地.因为strncpy的第二个参数类型为const char *.所以编译器
会自动将CString类转换成const char *.很多人对LPCTSTR是什么东西迷惑不解,让我们
来看看:
1.LP表示长指针,在win16下有长指针(LP)和短指针(P)的区别,而在win32下是没有区别
的,都是位.所以这里的LP和P是等价的.
2.C表示const
3.T是什么东西呢,我们知道TCHAR在采用UNICODE方式编译时是wchar_t,在普通时编译成char
那么就可以看出LPCTSTR(PCTSTR)在UINCODE时是const wchar_t
*,PCWSTR,LPCWSTR,在
多字节字符模式时是const char *,PCSTR,LPCSTR.
接下来我们看在非UNICODE情况下,怎样将CString转换成char *,很多初学者都为了方便
//采用如下方法:
(char *)(LPCSTR)str.这样对吗?我们首先来看一个例子:
CString str("aa");
strcpy((char *)(LPCTSTR)str,"aaaaaaaa");
cout<<(LPCTSTR)str<<endl;
在Debug下运行出现了异常,我们都知道CString类内部有自己的字符指针,指向一个已分
配的字符缓冲区.如果往里面写的字符数超出了缓冲区范围,当然会出现异常.但这个程
序在Release版本下不会出现问题.原来对CString类已经进行了优化.当需要分配的内存
小于字节时,直接分配字节的内存,以此类推,一般CString类字符缓冲区的大小为
64,128,256,512...这样是为了减少内存分配的次数,提高速度.
那有人就说我往里面写的字符数不超过它原来的字符数,不就不会出错了,比如
CString str("aaaaaaa");
strcpy((char *)(LPCTSTR)str,"aa");
cout<<(LPCTSTR)str<<endl;
//这样看起来是没什么问题.我们再来看下面这个例子:
CString str("aaaaaaa");
strcpy((char *)(LPCTSTR)str,"aa");
cout<<(LPCTSTR)str<<endl;
cout<<str.GetLength()<<endl;
//我们看到str的长度没有随之改变,继续为而不是.还有更严重的问题:
CString str("aaaaaaa");
CString str1 = str;
strcpy((char *)(LPCTSTR)str,"aa");
cout<<(LPCTSTR)str<<endl;
cout<<(LPCTSTR)str1<<endl;
按说我们只改变了str,str1应该没有改变呀,可是事实时他们都变成了"aa".难道str和
str1里面的字符指针指向的缓冲区是一个.我们在Effective C++里面得知,如果你的类
内部有包含指针,请为你的类写一个拷贝构造函数和赋值运算符.不要让两个对象内部的
指针指向同一区域,而应该重新分配内存.难道是微软犯了错?
原来这里还有一个"写时复制"和"引用计数"的概念.CString类的用途很广,这样有可能
在系统内部产生大量的CString临时对象.这时为了优化效率,就采用在系统软件内部广
泛使用的"写时复制"概念.即当从一个CString产生另一个CString并不复制它的字符缓
冲区内容,而只是将字符缓冲区的"引用计数"加.当需要改写字符缓冲区内的内容时,才
分配内存,并复制内容.以后我会给出一个"写时复制"和"引用计数"的例子
我们回到主题上来,当我们需要将CString转换成char *时,我们应该怎么做呢?其时只是
//麻烦一点,如下所示:
CString str("aaaaaaa");
strcpy(str.GetBuffer(10),"aa");
str.ReleaseBuffer();
当我们需要字符数组时调用GetBuffer(int n),其中n为我们需要的字符数组的长度.使
用完成后一定要马上调用ReleaseBuffer();
还有很重要的一点就是,在能使用const char *的地方,就不要使用char *
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/cobay/archive/2008/12/19/3556307.aspx