在静态内存分配VS C运行时的动态链接 [英] Memory Allocation in Static vs Dynamic Linking of C Runtime
问题描述
我的程序的体系结构包括插件（DLL）和exe文件（显然）。我们是唯一的插件提供商。有人告诉我，在分配一个插件的内存，然后在EXE code释放，这是一个潜在的问题，如果我们静态链接的C运行时。但是，如果我们动态链接它，有一只堆和C运行时能够获得它的全部。我们切换到动态链接这个建议的基础上，但所有我们的看到的从交换机是与新运行时的分发和安装头疼和麻烦。 （不知道是什么，我们的避免的在内存分配问题条款。）
My program's architecture involves plugins (dlls) and the exe (obviously). We are the only plugin provider. I was told that allocating memory in a plugin and then freeing it in the exe code was a potential problem if we statically linked the c runtime. However, if we dynamically linked it, there was just one heap and the c runtime had access to all of it. We switched to dynamic linking on the basis of this advice, but all we've seen from the switch is headaches and trouble related to distribution and installation of the new runtimes. (Don't know what we avoided in terms of memory allocation problems.)
什么是内存分配的影响？说一个插件分配内存和EXE释放它。是否有静态的不同的行为VS动态链接的C运行时？我们将会有麻烦静态链接C运行时，如果我们使用的插件？如果我们切换回静态链接，将那些乱七八糟了内存泄漏检测和崩溃转储报告？
What are the memory allocation implications? Say a plugin allocates memory and the exe frees it. Is there different behavior between the static vs dynamically linked c runtime? Will we have trouble statically linking the c runtime if we use plugins? If we switch back to static linking, will that mess up the memory leak detection and crash dump reporting?
是与评论上的
还有一个在 HTTP一些讨论：/ /msdn.microsoft.com/en-us/library/abx4dbyh(v=VS.100).aspx 。
推荐答案
如果您想从堆在一个模块中分配，并免费在另一个，那么你只需要动态链接的运行时间。更重要的是，所有各方都必须动态链接的相同的运行时间。一旦你这样做就会有什么问题。
If you want to allocate from the heap in one module, and free in another then you simply have to dynamically link the runtime. What's more, all parties must dynamically link the same runtime. Once you do that then there will be no problems.
现在，这是一个相当严重的制约强加给你的插件，做它之前，你应该三思而后行。强制所有插件作者在锁步与您升级是一个沉重的税收。我建议你考虑重构你的接口，这样的分配与取消分配一个单独的模块中总是成对出现。该升降机我上面描述的限制，使生活更容易为你的插件作者。
Now, this is quite a severe constraint to impose on your plugins and you should think twice before doing it. Forcing all plugin authors to upgrade in lock-step with you is a heavy imposition. I would recommend that you consider refactoring your interface so that allocations are always paired with deallocations within a single module. This lifts the constraints I describe above and makes life easier for your plugin authors.
至于为什么你仍然运行时错误的痛苦，这是很难说。我的猜测是，并不是所有的模块都链接到的同一版本的运行时。
As for why you are still suffering from runtime errors, that's hard to tell. My guess is that not all modules are linking against the same version of the runtime.
在评论你的状态，你控制所有插件。这意味着我在上面讨论的约束不是一种负担，因为它很容易让你使用相同的编译器版本的所有模块。然而，随着跨模块堆访问动态链接的规则仍然存在。您必须使用动态链接对运行时的相同单机版。
In the comments you state that you control all plugins. That means the constraints I discuss above are not an imposition since it is easy for you to use the same compiler version for all modules. However, the rules for dynamic linking with cross-module heap access remain. You must use dynamic linking against the same single version of the runtime.
这篇关于在静态内存分配VS C运行时的动态链接的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
