关于内存泄漏 - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>Programming - 葵花宝典

关于内存泄漏

关于内存泄漏# Programming - 葵花宝典

r*q2005-08-14 07:08

1 楼

这里很多人怀疑我的方法是否有效。不是我不想写出来，
而是实在太简单，实在不值得写出来。我个人认为是个人
都应该想得出。这些人无法想出的原因，我个人认为并不
是水平不够，而是已走火入魔。在MFC和类似环境熏陶下
成长的程序员，习惯了用最复杂的方法完成最简单的认为，
而不能理解世界上还有如此简单的方法。
由于我明天要赶飞机，今天没有时间把我的方法写出来。
虽然简单，要说明白还是要不少的文字。我在此只能重申
一下，我的方法只用构造函数和析构函数，唯一原则是
不用"裸"的new/delete/alloc...
过两天如有时间我会把我的方法写出来。我并不企望能改变
那些已经走火入魔的人，只希望尚未走火入魔的人少一些误
入歧途。在这几天也许有人已经找到解决方案，如你能代我
写出来最好了，因为我很快又要回中国，行程很紧。
在此不由得联想到版名，"欲练此功，引刀自宫"，对那些
走火入魔的人，可能确实如此//hehe

t*l2005-08-14 07:08

2 楼

真是唐。不过还是很期待看到你的方法，多谢

【在 r*******q 的大作中提到】

: 这里很多人怀疑我的方法是否有效。不是我不想写出来，
: 而是实在太简单，实在不值得写出来。我个人认为是个人
: 都应该想得出。这些人无法想出的原因，我个人认为并不
: 是水平不够，而是已走火入魔。在MFC和类似环境熏陶下
: 成长的程序员，习惯了用最复杂的方法完成最简单的认为，
: 而不能理解世界上还有如此简单的方法。
: 由于我明天要赶飞机，今天没有时间把我的方法写出来。
: 虽然简单，要说明白还是要不少的文字。我在此只能重申
: 一下，我的方法只用构造函数和析构函数，唯一原则是
: 不用"裸"的new/delete/alloc...

c*r2005-08-14 07:08

3 楼

我猜想这方法就是wrapping new/delete with constructor/destructor,
thus forcing delete/release be called when the function exists.
这样可以避免在一个function里分配和释放没有配对出现引起的内存泄露.
但更多情况下内存泄露的原因是的objects that live across functions,
especial across modules, layers, threads, ...

【在 t*****l 的大作中提到】

: 真是唐。不过还是很期待看到你的方法，多谢

w*r2005-08-14 07:08

4 楼

Come on, if it's really that simple, it would cost you less time
than typing all these chinese characters.

【在 r*******q 的大作中提到】

w*r2005-08-14 07:08

5 楼

How do you wrap new in the constructor?
What if you forget to call delete() in the destructor?

【在 c*r 的大作中提到】

: 我猜想这方法就是wrapping new/delete with constructor/destructor,
: thus forcing delete/release be called when the function exists.
: 这样可以避免在一个function里分配和释放没有配对出现引起的内存泄露.
: 但更多情况下内存泄露的原因是的objects that live across functions,
: especial across modules, layers, threads, ...

g*g2005-08-14 07:08

6 楼

I doubt there's any simple way to do that.
Otherwise it could be automatically generated by compiler.
It takes a live VM to do that job.
If you use STL exclusively however, can relieve the burden.

【在 c*r 的大作中提到】

c*e2005-08-14 07:08

7 楼

there is no need to doubt about that.
if one wants to trade managebility with effeciency, definitely u can do that
or maybe just switch to java persay.

【在 g*****g 的大作中提到】

: I doubt there's any simple way to do that.
: Otherwise it could be automatically generated by compiler.
: It takes a live VM to do that job.
: If you use STL exclusively however, can relieve the burden.

N*r2005-08-14 07:08

8 楼

the point is that C++ code does not run a VM, so there is no way
to write a garbage collecter on par with the one in Java.
Without changing the language, a garbage collector for C++ will be
either incomplete, or inefficient compared to the Java one.

【在 c********e 的大作中提到】

: there is no need to doubt about that.
: if one wants to trade managebility with effeciency, definitely u can do that
: or maybe just switch to java persay.

a*f2005-08-14 07:08

9 楼

I think an pair of overloaded new and delete functions could be pretty helpful
in many cases. It records each allocated/deallocated memory block and
the statement allocating/deleting it. After the main program is ended, it could
output the memory blocks which have not been released yet and the corresponding
statements allocating them.
Besides, we could cache the memory blocks if your program allocate/deallocate
small memory blocks frequently, and the performance fo the program could be
improved

【在 N*********r 的大作中提到】

: the point is that C++ code does not run a VM, so there is no way
: to write a garbage collecter on par with the one in Java.
: Without changing the language, a garbage collector for C++ will be
: either incomplete, or inefficient compared to the Java one.

c*r2005-08-14 07:08

10 楼

This is way to detect/debug memory leakage, not a way to avoid it.

helpful
could
corresponding
deallocate
code.
of

【在 a***f 的大作中提到】

: I think an pair of overloaded new and delete functions could be pretty helpful
: in many cases. It records each allocated/deallocated memory block and
: the statement allocating/deleting it. After the main program is ended, it could
: output the memory blocks which have not been released yet and the corresponding
: statements allocating them.
: Besides, we could cache the memory blocks if your program allocate/deallocate
: small memory blocks frequently, and the performance fo the program could be
: improved