注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

还东国的博客

行之苟有恒,久久自芬芳

 
 
 

日志

 
 

再谈GetBuffer--ReleaseBuffer问题  

2011-09-20 12:35:39|  分类: C++(VC)编程 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

再谈GetBuffer--ReleaseBuffer问题
今天又遇到了这个问题,使用GetBuffer--ReleaseBuffer后程序报错,“This may be due to a corruption of the heap, and indicates a bug in G2Client.exe or any of the DLLs it has loaded.
The output window may have more diagnostic information”。
一时间摸不着头绪,回头想了想,怀疑到可能是使用了GetBuffer这个函数造成的,使用的代码如下:
 bTemp    = (BYTE *)sGateWay.GetBuffer(sGateWay.GetLength()); 
 m_cUssnManage.SendNetCmdNoArg(sSocket,bTemp,0x6);     
 sGateWay.ReleaseBuffer();
因为在上一篇的这种问题的分析上我们知道,在GetBuffer后整个内存的区域是不稳定的,也就是说,整个字符串的完整性是不能得到保障的,所以我们在上次没有释放时使用CString的各种操作函数,出现了这样和那样的奇怪的现象。
这次再次遇到这种现象,那就是上面的代码中,把bTemp中的数据进行了修改或者说是运算也成,那么在整个函数完成,释放临时变量sGetWay时,就会报上面的那个奇怪的错误。通过这两次分析我们明白,在GetBuffer后,没有ReleaseBuffer之前,做任何关于这个CString及其演生的字符串,数组时候儿,都要千万小心,再小心。(这个现象的主要原因是修改了缓冲区的数据并且越界进行了修改,我们知道,在新的编译器中,越界的处理是在内存释放的时候儿进行控制的,所以在释放对象时,造成了这个异常的现象)
另外,看下例:
我们定义一个函数返回一个CString型的变量,现定义一个CString型的变量:
CString GetStr();
CString sStr;
char* bTemp;
bTemp = GetStr().GetBuffer(); //ERROR
sStr = GetStr();
bTemp = sStr.GetBuffer();     //OK
原因不言而喻,前者函数返回了一个临时变量,临时变量会被释放掉,所以你在跟踪时可能是正确的,但在使用时就有可能会出错,但是用后面一种方法,临时将变量保存起来,等于重新生成了一个新的字符串的拷贝,就没有问题了。
还是那句话:
 纸上学来终觉浅,决知此事要躬行。

  评论这张
 
阅读(906)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017