如果 dll 的导出没有改变，我是否需要重建它？
这可能是一个非常愚蠢的问题。但假设我有一个 DLL (test.dll)，带有一些导出，在构建时会生成一个导入库 (test.lib)。我有一个使用此 DLL 的应用程序 TestApp。
现在，如果我想更改 DLL 中某些函数的实现，并且保持导出不变，我是否需要重建使用此 DLL/导入库的应用程序？
谢谢。
This is probably a very stupid question. But assume that I have a DLL (test.dll), with some exports, that when built generates an import library (test.lib). I have an application TestApp that uses this DLL.
Now, if I want to change some functions' implementation in the DLL, and I keep the exports unchaged, do I need to rebuild my application that uses this DLL/import lib?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不需要。您不需要针对 dll 进行重建。
假设您的应用程序在 Windows XP 上运行，有一天 Windows 7 出现了。即使 user32.dll、kernel32.dll 等系统 dll 已更新，相同的应用程序仍可继续工作而无需重建！
No. You do NOT need to rebuild against the dll.
Consider that you application works on Windows XP and one day Windows 7 comes. The same application continue to work without rebuilding even though system dlls like user32.dll, kernel32.dll are updated!
不。共享库（相对于静态库）的目的之一正是这样：只要外部看到的内容（导出的定义/函数）没有改变，使用它的应用程序就不需要重新编译。
no. One of the purposes of shared library (vs static library) is excactly this: as long as what the outside sees does not change (the exported definitions/functions), the aplications using it do not need recompiling.
如果函数是 C 函数，并且您不更改正在传递的任何结构的定义，则无需重建应用程序。
如果 DLL 导出 C++ 类，则导入模块确实需要重新构建 - 即使方法签名没有更改，C++ 类导出也存在泄漏：为类分配空间时，没有定义导出的分配器函数（通过默认），因此导入模块必须在调用（导出的）构造函数之前猜测要分配多少空间。它通过解析类定义来构建猜测。
这样做的不幸后果是，即使您小心翼翼地只更改类的实现细节 - 即使方法签名保持不变并且 dll 将成功加载，应用程序也会在创建新实例时分配不正确的字节数在堆或堆栈上。
If the functions are C functions, and you do not change the definition of any structures that are being passed there is no need to rebuild the app.
If the DLL exports C++ classes, then the importing module does need to be rebuilt - Even though the method signatures do not change, C++ class exporting is leaky: When allocating space for the class, there is no defined allocator function that is exported (by default) as such the importing module has to guess how much space to allocate, before the calling the (Exported) constructor. It builds that guess by parsing the classes definition.
The unfortunate consequence of this is, even if you are careful to only change a classes implementation details - even though the method signatures will remain the same and the dll will load successfully, the app will allocate the incorrect number of bytes when creating a new instance on the heap or stack.