dll与视觉工作室之间的循环依赖 [英] circular dependencies between dlls with visual studio
问题描述
foo（int i）
{
if（ i> 0）
bar（i -i）;
}
- >应该编译成foo.dll
bar（int i）
{
if（i> 0）
foo（i - i）;
}
- >应该编译成bar.dll
我在visual studio中创建了两个项目，一个用于foo，一个用于bar。通过玩参考和编译几次，我设法得到我想要的dll。我想知道，视觉工作室是否提供了一种干净的方法。
如果foo更改，则不需要重新编译条，因为我只取决于条形码的签名，而不是执行吧。如果两个dll都有lib存在，我可以重新编译新的功能到两者之一，整个系统仍然有效。
我正在尝试的原因是我有具有循环依赖性的传统系统，其目前是静态链接的。我们希望由于各种原因转向dll。我们不想等到我们清理所有的循环依赖项。我正在考虑解决方案，并尝试使用gcc在linux上的一些东西，那里有可能做我建议的。所以你可以有两个相互依赖的共享库，可以彼此独立构建。
我知道循环依赖不是一件好事，但是这不是我想要的讨论。
它适用于类Unix系统的原因是因为它们执行实际链接加载时分辨率。一个共享库不知道它的功能定义将来自哪里，直到它被加载到一个进程。这个缺点是你也不知道。一个库可以在任何其他库中找到并调用函数（甚至是首先启动该进程的主二进制文件）。另外默认情况下，共享库中的所有内容都将导出。
Windows根本不工作。只有显式导出的东西被导出，并且所有导入必须在库链接时被解析，到此为止，提供每个导入的功能的DLL的身份已被确定。这需要一个导入库链接。
但是，你可以（有一些额外的工作）解决这个问题。使用 LoadLibrary 打开任何您喜欢的DLL，然后使用 GetProcAddress 找到要调用的函数。这样，没有限制。但是正常方法的限制是有原因的。
当你想从静态库转换到DLL时，听起来你假设你应该每个静态库变成一个DLL。这不是你唯一的选择。只有当您将代码识别为适合不具有圆形性的分层设计的独立模块时，为什么不开始将代码移动到DLL中？这样你现在就可以开始这个过程，但是一次又一次地攻击它。
I have a circular dependency between two functions. I would like each of these functions to reside in its own dll. Is it possible to build this with visual studio?
foo(int i)
{
if (i > 0)
bar(i -i);
}
-> should compile into foo.dll
bar(int i)
{
if (i > 0)
foo(i - i);
}
-> should compile into bar.dll
I have created two projects in visual studio, one for foo and one for bar. By playing with the 'References' and compiling a few times, I managed to get the dll's that I want. I would like to know however whether visual studio offers a way to do this in a clean way.
If foo changes, bar does not need to be recompiled, because I only depend on the signature of bar, not on the implementation of bar. If both dll's have the lib present, I can recompile new functionality into either of the two and the whole system still works.
The reason I am trying this is that I have a legacy system with circular dependencies, which is currently statically linked. We want to move towards dll's for various reasons. We don't want to wait until we clean up all the circular dependencies. I was thinking about solutions and tried out some things with gcc on linux and there it is possible to do what I suggest. So you can have two shared libraries that depend on each other and can be built independent of each other.
I know that circular dependencies are not a good thing to have, but that is not the discussion I want to have.
The reason it works on Unix-like systems is because they perform actual linking resolution at load time. A shared library does not know where its function definition will come from until it's loaded into a process. The downside of this is that you don't know either. A library can find and call functions in any other library (or even the main binary that launched the process in the first place). Also by default everything in a shared library is exported.
Windows doesn't work like that at all. Only explicitly exported things are exported, and all imports must be resolved at library link-time, by which point the identity of the DLL that will supply each imported function has been determined. This requires an import library to link against.
However, you can (with some extra work) get around this. Use LoadLibrary to open any DLL you like, and then use GetProcAddress to locate the functions you want to call. This way, there are no restrictions. But the restrictions in the normal method are there for a reason.
As you want to transition from static libraries to DLLs, it sounds like you're assuming that you should make each static library into a DLL. That's not your only option. Why not start moving code into DLLs only when you identify it as a self-contained module that fits into a layered design with no circularity? That way you can begin the process now but still attack it a piece at a time.
这篇关于dll与视觉工作室之间的循环依赖的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
