C++ MFC CStringList – 内存清理,可能存在内存泄漏

huangapple go评论86阅读模式
英文:

C++ MFC CStringList - Memory clean up, possible memory leaks

问题

我正在使用一个 CStringList 对象。我想知道是否因为我如何操作这个列表而导致我的代码可能会出现内存泄漏。

我有一个类成员变量:

CStringList m_ListOfSz;

我使用 AddTail() 函数将 CString 对象添加到列表中:

CString sz1 = "字符串1";
CString sz2 = "字符串2";
m_ListOfSz.AddTail(sz1);
m_ListOfSz.AddTail(sz2);

在程序的某个时刻,我使用 RemoveAll() 函数来移除我添加到列表中的所有 CString 对象。

由于我没有为这些 CString 对象分配内存,我不必释放与它们相关的内存,是吗?

我可以依赖系统来正确清理内存吗?

英文:

I am using a CStringList object. I am wondering whether my code may result in memory leaks or not because of how I manipulate this list.

I have a class member variable:

CStringList m_ListOfSz;

I use the AddTail() function to add CString objects to the list:

CString sz1 = "A string 1";
CString sz2 = "A string 2";
m_ListOfSz.AddTail(sz1);
m_ListOfSz.AddTail(sz2);

At some point in the program, I use the RemoveAll() function to remove all the CString objects I added to the list.

As I didn't allocate memory for these CString objects, I don't have to free memory related to them, or do I?

Can I rely on the system to clean up the memory properly?

答案1

得分: 4

> 由于我没有为这些 CString 对象分配内存,我不必释放与它们相关的内存,对吗?

不需要,因为你没有为这些对象分配动态内存,所以没有需要释放的内容。

创建 CString 会在需要时内部分配内存。当销毁 CString 时,它会释放它已分配的任何内存。

将字符串添加到 CStringList 时,也会根据需要内部分配内存。当从列表中删除字符串或销毁列表时,它将释放已分配的相关内存。

所有这些都会自动管理。

> 我可以依赖系统来正确清理内存吗?

通常情况下,是的,如果你正确使用这些对象的话。

内存泄漏只会发生在你动态创建对象并没有销毁它们的情况下。

根据你的示例,看起来并没有直接这样做。它是在自动内存中创建 CString/List 对象,因此它们的生命周期由编译器管理,当它们超出作用域时,编译器会为你处理必要的清理。

但是,你的 m_ListOfSz 对象是一个类的成员。如果该类是动态创建的,那么如果该类对象没有正确销毁,m_ListOfSz 和其中存储的所有 CString 可能会发生内存泄漏。根据你的帖子中的上下文不足以确定是否实际上是这种情况。

英文:

> As I didn't allocate memory for these CString objects, I don't have to free memory related to them, or do I?

No, you do not. Since you are not allocating any dynamic memory yourself for the objects, there is nothing for you to free.

Creating a CString will allocate memory internally for itself as needed. When the CString is destroyed, it frees any memory that it had allocated.

Adding strings to a CStringList will likewise allocate memory internally as needed. When strings are removed from the list, or the list is destroyed, it will free the relevant memory that it had allocated.

All of this is managed automatically for you.

> Can I rely on the system to clean up the memory properly?

Typically yes, if you are using the objects correctly.

Leaks can only occur if you create the objects dynamically and don't destroy them.

Your example does not appear to be doing that, at least not directly. It is creating the CString/List objects in automatic memory, so their lifetimes are managed by the compiler, which will handle the necessary cleanup for you when they go out of scope.

However, your m_ListOfSz object is a member of a class. If that class is created dynamically, then m_ListOfSz and all of its stored CStrings can be leaked if that class object is not destroyed properly. There is not enough context in your post to determine is that is actually the case or not.

答案2

得分: 1

The CString objects indeed allocate memory to store the string contents (the "buffer"). This memory is released by their destructors. Also, the CStringList destructor will destroy its items in the list. So to answer your question, no, you don't need to release anything yourself, they will all be released when the CStringList object gets out of scope (or you call delete, if it was created by calling `new").

英文:

The CString objects indeed allocate memory to store the string contents (the "buffer"). This memory is released by their destructors. Also, the CStringList destructor will destroy its items in the list. So to answer your question, no, you don't need to release anything yourself, they will all be released when the CStringList object gets out of scope (or you call delete, if it was created by calling new).

huangapple
  • 本文由 发表于 2023年3月21日 00:42:11
  • 转载请务必保留本文链接:https://go.coder-hub.com/75793017.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定