谁将堆分配给 DLL?

发布于 2024-10-13 12:26:14 字数 189 浏览 2 评论 0原文

假设我使用 MS Visual Studio 2005/2008 开发一个 DLL,例如 1.dll,然后我在加载时(使用头文件和 .lib 文件)将此 DLL 链接到控制台应用程序,例如 1.exe,然后在 DLL 内时,如果我在运行时分配内存,那么谁将堆(自由存储)分配给 DLL。

据我了解,DLL 使用进程的地址空间来存储数据、代码和堆栈。

Suppose I develop a DLL, say 1.dll using MS visual studio 2005/2008, then I link this DLL to a console application, say 1.exe, at load time (using header file and .lib file) then When inside DLL, if I am allocating memory at run time, then who allocates heap (free store) to the DLL.

As I understand that DLL uses process's address space for data, code and stack.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

把回忆走一遍 2024-10-20 12:26:14

当您创建 Dll 时 - 您总是用某种语言编写它 - 在您的情况下是使用 Visual Studio 2005 或 2008 的 C++。

在这种情况下,C++ 运行时负责创建其自由存储并决定如何分配它。

具体来说,如果您使用 Dll 运行时选项,则单个 dll - msvcrtxx.dll - 管理在所有 dll 和与该 dll 链接的 exe 之间共享的单个自由存储区。

如果在创建 exe 和 dll 时使用静态运行时选项,则 exe 和每个 dll 都会获得自己的内置 libc 实例,并具有自己的自由存储管理。

When you make a Dll - you always write it in some Language - in your case C++ using Visual Studio 2005 or 2008.

In which case it is the C++ runtime that is responsible for creating its freestore and deciding how to allocate it.

Specifically, if you use the Dll runtime option, then a single dll - msvcrtxx.dll - manages a single freestore that is shared between all dll's, and the exe, that are linked against that dll.

If you use the static runtime option when beuiding your exe and dlls, then the exe and each dll gets its own instance of libc built in, with its own freestore management.

梦断已成空 2024-10-20 12:26:14

当您在 DLL 内执行代码时,代码将在进程上下文中以及正在调用的线程上执行,这样,内存就会在进程空间中分配。

DLL 的实现当然可以跨越新线程或新进程。在后一种情况下,内存分配将在新的分叉进程中进行。

这意味着当 1.exe 执行 DLL 时,所有分配的内存(包括堆栈)都会进入您的进程内存空间(即,如果 DLL 分配 1 GB 内存,那么它将反映在您的进程内存消耗中)。

When you execute code inside a DLL the code is executed in the context of your process and on the thread that is calling and, in that way, memory is allocated in your process space.

The implementation of the DLL can of course span new threads or new processes. In the latter case the memory allocation will take place in the new forked process.

That means when 1.exe executes the DLL all memory allocated (including the stack) goes to your process memory space (i.e. if the DLL allocates 1 GB of memory then it will reflect in your process memory consumption).

我喜欢麦丽素 2024-10-20 12:26:14

你负责内存管理。 DLL有单独的堆,所以你需要自己进行管理。当然,根据您的环境,可能会有专门的新建/删除功能以方便您使用。

有两种类型的动态内存需要处理,和分开

  • 您可以使用调用进程堆,但显然,每个调用进程的堆都是不同的。因此,您仅将其用于取决于调用者的数据。

  • 对于 DLL 一般使用的内存,与调用者无关,您必须使用 HeapCreate 及其同级函数。

小心不要将记忆的责任转嫁到其他任何事情上。你的 DLL 分配的内容,你的 DLL 都会删除——否则,你会遇到麻烦。这应该是基本规则,但是通过 GC,有些人忘记了如何负责任地使用内存,所以我提一下。

You do the memory management. DLLs have separate heaps, so you need to do the management yourself. Of course, depending on your environment, there may be an specialized new/delete available for your convenience.

There are two types of dynamic memory to handle, and to keep apart:

  • You can use the calling process' heap, but that will be a different one for every calling process, obviously. So you use that only for data depending on the caller.

  • For the memory your DLL uses in general, independent of caller, you'll have to get a separate "private" heap, using HeapCreate and its sibling functions.

Be careful not to pass on the responsibility for that memory to anything else. What your DLL allocates, your DLL will delete - otherwise, you'll get trouble. That should be the basic rules, but over GC some people forget how use memory responsibly, so I mention it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文