CString

最新推荐文章于 2022-05-17 15:03:42 发布

大童小童

最新推荐文章于 2022-05-17 15:03:42 发布

阅读量1.9k

点赞数

文章标签： microsoft mfc delete 编程 string 工作

关于Cstring 类

Stevencao@benq.com

2003-11-6

看了很多人写的程序，包括我自己写的一些代码，发现很大的一部分bug是关于MFC类中的Cstring的错误用法的.出现这种错误的原因主要是对Cstring的实现机制不是太了解。

Cstring是对于原来标准c中字符串类型的一种的包装。因为，通过很长时间的编程，我们发现，很多程序的bug多和字符串有关，典型的有：缓冲溢出、内存泄漏等。而且这些bug都是致命的，会造成系统的瘫痪。因此c++里就专门的做了一个类用来维护字符串指针。标准c++里的字符串类是string，在microsoft MFC类库中使用的是Cstring类。通过字符串类，可以大大的避免c中的关于字符串指针的那些问题。

这里我们简单的看看Microsoft MFC中的Cstring是如何实现的。当然，要看原理，直接把它的代码拿过来分析是最好的。MFC里的关于Cstring的类的实现大部分在strcore.cpp中。

Cstring就是对一个用来存放字符串的缓冲区和对施加于这个字符串的操作封装。也就是说，Cstring里需要有一个用来存放字符串的缓冲区，并且有一个指针指向该缓冲区，该指针就是LPTSTR m_pchData。但是有些字符串操作会增建或减少字符串的长度，因此为了减少频繁的申请内存或者释放内存，Cstring会先申请一个大的内存块用来存放字符串。这样，以后当字符串长度增长时，如果增加的总长度不超过预先申请的内存块的长度，就不用再申请内存。当增加后的字符串长度超过预先申请的内存时，Cstring先释放原先的内存，然后再重新申请一个更大的内存块。同样的，当字符串长度减少时，也不释放多出来的内存空间。而是等到积累到一定程度时，才一次性将多余的内存释放。

还有，当使用一个Cstring对象a来初始化另一个Cstring对象b时，为了节省空间，新对象b并不分配空间，它所要做的只是将自己的指针指向对象a的那块内存空间，只有当需要修改对象a或者b中的字符串时，才会为新对象b申请内存空间，这叫做写入复制技术，然后再观察nNewLen，发现这个时候已经是我们想要的值8了。

从Cstring的机理上也可以看出:GetBuffer返回的是CstringData对象里的字符串缓冲的首地址。根据这个地址，我们对这个地址里的值进行的修改，改变的只是CstringData里的字符串缓冲中的值， CstringData中的其他用来描述字符串缓冲的属性的值已经不是正确的了。比如此时CstringData:: nDataLength很显然还是原来的值20，但是现在实际上字符串的长度已经是8了。也就是说我们还需要对CstringData中的其他值进行修改。这也就是需要调用ReleaseBuffer()的原因了。

正如我们所预料的，ReleaseBuffer源代码中显示的正是我们所猜想的:

CopyBeforeWrite(); // just in case GetBuffer was not called

if (nNewLength == -1)

nNewLength = lstrlen(m_pchData); // zero terminated

ASSERT(nNewLength = GetData()-nAllocLength);

GetData()-nDataLength = nNewLength;

m_pchData[nNewLength] = ‘/0‘;

其中CopyBeforeWrite是实现写拷贝技术的，这里不管它。

下面的代码就是重新设置CstringData对象中描述字符串长度的那个属性值的。首先取得当前字符串的长度，然后通过GetData()取得CstringData的对象指针，并修改里面的nDataLength成员值。

但是，现在的问题是，我们虽然知道了错误的原因，知道了当修改了GetBuffer返回的指针所指向的值之后需要调用ReleaseBuffer才能使用Cstring的其他operations时，我们就能避免不在犯这个错误了。答案是否定的。这就像虽然每一个懂一点编程知识的人都知道通过new申请的内存在使用完以后需要通过delete来释放一样，道理虽然很简单，但是，最后实际的结果还是有由于忘记调用delete而出现了内存泄漏。

实际工作中，常常是对GetBuffer返回的值进行了修改，但是最后却忘记调用ReleaseBuffer来释放。而且，由于这个错误不象new和delete人人都知道的并重视的，因此也没有一个检查机制来专门检查，所以最终程序中由于忘记调用ReleaseBuffer而引起的错误被带到了发行版本中。

要避免这个错误，方法很多。但是最简单也是最有效的就是避免这种用法。很多时候，我们并不需要这种用法，我们完全可以通过其他的安全方法来实现。

比如上面的代码，我们完全可以这样写:

CString str1("This is the string 1");

int nOldLen = str1.GetLength();

str1 = "modified";

int nNewLen = str1.GetLength();

但是有时候确实需要，比如:

我们需要将一个Cstring对象中的字符串进行一些转换，这个转换是通过调用一个dll里的函数Translate来完成的，但是要命的是，不知道什么原因，这个函数的参数使用的是char*型的:

DWORD Translate( char* pSrc， char *pDest， int nSrcLen， int nDestLen );

这个时候我们可能就需要这个方法了:

Cstring strDest;

Int nDestLen = 100;

DWORD dwRet = Translate( _strSrc.GetBuffer( _strSrc.GetLength() )，

strDest.GetBuffer(nDestLen)，

_strSrc.GetLength()， nDestlen );

_strSrc.ReleaseBuffer();

strDest.ReleaseBuffer();

if ( SUCCESSCALL(dwRet) )

{

}

if ( FAILEDCALL(dwRet) )

{

}

的确，这种情况是存在的，但是，我还是建议尽量避免这种用法，如果确实需要使用，请不要使用一个专门的指针来保存GetBuffer返回的值，因为这样常常会让我们忘记调用ReleaseBuffer。就像上面的代码，我们可以在调用GetBuffer之后马上就调用ReleaseBuffer来调整Cstring对象。

2. LPCTSTR

关于LPCTSTR的错误常常发生在初学者身上。

例如在调用函数

DWORD Translate( char* pSrc， char *pDest， int nSrcLen， int nDestLen );

时，初学者常常使用的方法就是:

int nLen = _strSrc.GetLength();

DWORD dwRet = Translate( (char*)(LPCTSTR)_strSrc)，

(char*)(LPCTSTR)_strSrc)，

nLen，

nLen);

if ( SUCCESSCALL(dwRet) )

{

}

if ( FAILEDCALL(dwRet) )

{

}

他原本的初衷是将转换后的字符串仍然放在_strSrc中，但是，当调用完Translate以后之后再使用_strSrc时，却发现_strSrc已经工作不正常了。检查代码却又找不到问题到底出在哪里。

其实这个问题和第一个问题是一样的。Cstring类已经将LPCTST重载了。在Cstring中LPCTST实际上已经是一个operation了。对LPCTST的调用实际上和GetBuffer是类似的，直接返回CstringData对象中的字符串缓冲的首地址。

其C++代码实现是:

_AFX_INLINE CString::operator LPCTSTR() const

{ return m_pchData; }

因此在使用完以后同样需要调用ReleaseBuffer()。

但是，这个谁又能看出来呢?

其实这个问题的本质原因出在类型转换上。LPCTSTR返回的是一个const char*类型，因此使用这个指针来调用Translate编译是不能通过的。对于一个初学者，或者一个有很长编程经验的人都会再通过强行类型转换将const char*转换为char*。最终造成了Cstring工作不正常，并且这样也很容易造成缓冲溢出。

通过上面对于Cstring机制和一些容易出现的使用错误的描述，可以使我们更好的使用Cstring。