如何GC（删除）GetOpenFileName的线程

我注意到，当我使用函数GetOpenFileName时，很多线程在我的应用程序中被分配。在对话框关闭并且函数返回后，如何去除这些对象？我在这些线程中也遇到过SIGSEGV错误，这些错误不会导致我的应用程序崩溃，但它们仍然很烦人，因为它们不知从何而来，并且可能会在以后导致严重的内存问题，并且win32 api也不应该像这样有缺陷，应该如何？难道我做错了什么？如何GC（删除）GetOpenFileName的线程

另外我是c/C++的初学者，所以请不要太过于苛刻。

我的代码：

OPENFILENAME open; 
ZeroMemory(&open, sizeof(open)); 
char szFileName[2048] = {}; 

open.lStructSize = sizeof(OPENFILENAME); 
open.hwndOwner = NULL; 
open.lpstrFilter = "Képek\0*.jpg;*.jpeg;*.gif;*.png;*.bmp\0\0"; 
open.lpstrFile = szFileName; 
open.nFileOffset = 1; 
open.nMaxFile = 2048; 
open.lpstrTitle = "Képek kiválasztása.."; 
open.Flags = OFN_EXPLORER | OFN_ALLOWMULTISELECT | OFN_FILEMUSTEXIST; 

std::string links = ""; 
if (GetOpenFileName(&open)) { 
    ... 
}

来源

2013-07-29 19greg96

没有什么可以做这些线程。该对话框确实创建了一些由操作系统自己管理的工作线程，还可以安装第三方的资源管理器插件，这些插件也可以通过对话框使用资源管理器间接加载并创建自己的线程。只要对话框没有崩溃你的代码，就忽略多余的线程。它们是与您的应用无关的OS层线程。

来源

2013-07-29 23:23:58

那又如何分配内存？有没有办法摆脱那些东西？操作系统保持这些线程和内存与它们相关联的任何原因？他们是否被重用，如果我只在程序中调用这个函数，没有任何缓存的理由，这些都不能被控制吗？ – 19greg96

同样，这一切都发生*你的应用程序外*，所以忽略它。内存不在您的应用程序中分配，它在操作系统本身。线程由操作系统管理，而不是您的应用。不，这些行为都不能在您的应用内部进行控制。它对您的应用程序透明，由对话框和操作系统在内部使用，作为私有实现细节。所以就忽略它然后继续前进。 –

猜猜我可以忍受。但是我仍然有点难以理解它。 – 19greg96

如何GC（删除）GetOpenFileName的线程

回答

相关问题