扔分，CString的Bug，做过的请进

[Kerrie]

MFC的CString有不少Bug，例如内存泄漏，空值判断失误等，我们最近还发现了一个新的问题，CString的内存管理在release模式采用堆的方式进行管理，不过对已经生成的堆在程序运行期间却没有释放机制。举个例子，程序在运行期间，如果需要解析文档，则需要生成的大量的CString对象，解析完毕后，程序释放了这些CString对象，但是MFC并没有释放CString所占用的内存，如果程序长期运行，则会造成大量的无效空间占用。解决办法不明，考虑了一下，可能有如下几种方案：

1。在MFC的基础上创建CString内存释放函数，察看了MFC的实现代码，由于CString的内存管理类CFixedAlloc将物理内存管理的成员指针m_pBlocks、m_pNodeFree设成了protected。在外面的代码难以访问，有没有什么办法可以绕过C++的成员保护机制？

2。利用std::string，或者其他代码替代CString，不过MFC中大量采用CString作为库函数的接口，而且将无法使用CStringArray（不过stl有替代方案），对已有程序修改工作量不少。同时，不知道std::string等替代方案在内存碎块问题上考虑如何？因此此方案稍候考虑。

3。改写mfc中CString内存管理的实现，增加运行中无用内存释放机制，这个释放代码还好说，可是怎么让改动生效呢？重新编译mfc？怎么做？会导致什么结果？

做过的朋友请介绍一下经验，没做过的朋友请多讨论，大家研究研究。。。

[Kerrie]

to happyparrot(快乐鹦鹉)
关于释放问题：还是以解析文档为例，可以在解析函数中产生大量的函数局部变量类型的CString，函数执行完毕后，这些变量自然就被释放了。其它的方式还有很多，但方式基本上都是如此。我可以确信这些处理中不会出现new出的内存没有delete的问题，这个原因就先谢谢朋友的提醒，不做考虑了。

to handsomerun(毛毛)
CString的内存泄漏我也不是很清楚，网上的评论较常见的说法是说内部引用计数有关，在频繁使用CString指针或者引用时，可能会诱发这个Bug，不过我没遇到过，我们程序中的dll有不少导出变量和函数参数都是CString的，呵呵
那篇文章我也查到了，不过跟我目前调查的问题稍有区别，没有认真看，呵呵

to xiao_fang(frank)
重写？这个，我没那么厉害了，兄台也可以看看MFC中CString的实现，好像ms很闲的样子，写了那么多垃圾！笑笑而已，别当真。

to oyljerry(【勇敢的心】→ ㊣回家≡赞√㊣)
嗯，这是一个很容易出错的点，大家都需要注意点，呵呵

to vcleaner(我没当大哥很久了.......)
CString是有一些问题，不过用起来还是不错的，我们程序也写了不少年，但哪一块拿出来估计都比不上CString的质量，呵呵

to AntonlioX(做人要厚道)
线程不安全？怎么说，请多多指教，大家学习学习

to codewarrior(会思考的草)
嗯，最初发生这个现象，我们作了很多推测，都失败后，才逐步怀疑到CString上面，仔细看了mfc的似现代码后，才确认这个问题。不过这个情况应该属于比较特别的应用了，如果我来设计CString的版本，这个地方估计也不会留出这么一个接口。不过总体来说，CString还是一个非常不多的字符串类。

to linestyle(linestyle)
我也很喜欢用CString，std::string和char*我们也在用，不过用的不是一般的郁闷。

to Mr_Ldh(V1971.4)
我们最初也对自己的结论很不自信，仔细察看了CString的实现代码，才作词定论的，有兴趣我们可以讨论讨论：）

[Kerrie]

看CString的代码，遇到一个很好玩的宏，大家可以看看什么意思：

#define ROUND(x,y) (((x)+(y-1))&~(y-1))
#define ROUND4(x) ROUND(x, 4)

出处strcore.cpp 72行。这个宏我到现在还没有弄懂到底是什么玩意，只能从上下文和字面意思推测出出一个结论。大家有兴趣可以研究研究

[handsomerun]

嘿嘿，谢谢楼主，楼主好人，而且水平很高阿，学习

[teli_eurydice]

总之比较郁闷，呵呵，没有办法了

[jixingzhong]

郁闷 TOO

就是那么回事了...

[dzq138]

zzz

[Kerrie]

to ipgk(loboho)
这个？我门就不用作争论了，反正目的是要解决这个问题，对吗？呵呵

to jnifusun(求你整死我)
建议你看看CString自身的实现，这个问题不是一个明显的错误，很难一两句代码能说清楚，有兴趣的话我们可以讨论讨论

to ervinsas(sas)
羡慕，我们还在做迁移平台的评估工作呢，目前是无望了。

[蒋晟]

和所有动态内存分配的类一样，std::string也有内存碎片问题。解决的办法一个是用GC(对于VC来说自然的选择是编写托管和非托管混合程序)，另一个是调用HeapCompact。

[roscoe]

Kerrie()

那个是内存对齐用的,x : 原字节数,y:对齐字节.
返回大于x的最小的y的整数倍

[皮皮鲁]

mark

[DentistryDoctor]

我遇到一个问题，在多线程环境下用CString作为形参，偶尔会有未处理异常，如果换成LPCTSTR就不会有这个问题。

[会思考的草]

西西，把MFC某类挖出来在我的项目里改写的事情偶经常干……

[nonocast]

std::string

[lwsnake]

UP

[会思考的草]

呵呵，总之讨论下来结果有4：
1，改用.net的CString或者使用托管。
2，rebuild MFC
3，rewrite CString and repalce it。
4，确保每次字符个数>512。

目前好像就这么多，呵呵。

[nkwesley]

很郁闷的。
CString只能一般用用

[sad_4978]

这么激烈

[Kerrie]

折腾了半天，终于编译通过了，不过我自己的机器居然提示找不到afx.h，可能跟我安装vc时出了几个错有关。

如codewarrior(会思考的草)所说，我们目前能考虑的方案如下：
1，改用.net的CString或者使用托管。
——可行，但需要环境的支持，我们目前没这个条件了
2，rebuild MFC
——可行，风险不低
3，rewrite CString and repalce it。
——可行，已有代码有相当的工作量
4，确保每次字符个数>512
——对我们的程序来说，内存消耗较难以接受，而且还得修改原有代码，呵呵

这里感谢各位朋友的像助，特别是codewarrior(会思考的草)的大力支持，散分。

[hnhou]

好东西，学习一下

[sxxny]

我觉得楼主说的应该不能说他是一个Bug. 只是一策略问题.
MFC不回收内存肯定是有他的道理的. 比如考虑到效率问题等等.

你如果要涉及大规模的文字处理,当然要自己管理你的内存了, 你使用CString不是等于
把自己的命运交给别人了吗.