DLL设计：DLL需要访问一些应用程序函数/数据
我有一个带有一堆函数的 DLL。到目前为止，一切都很好，这就是 DLL 的用途。 但是，我的 DLL 中的某些函数需要从加载 DLL 的应用程序调用函数（或访问数据）。
App.exe :
std::vector<SomeClass> objectsList;
bool foo(void)
{
...
}
LoadLibrary( "something.dll" );
something.dll :
__declspec(dllexport) void someFunction(void)
{
if ( foo() )
{
objectsList[2].someAttr = 1;
}
}
据我所知，我的 DLL 代码不正确，因为 DLL 无法识别 foo 或 链接时的objectsList。所以，我看到的唯一方法是：
something.dll :
typedef bool fooType(void);
fooType* pFooFunc;
__declspec(dllexport) void setFoo(fooType* fooPtr)
{
pFooFunc = fooPtr;
}
__declspec(dllexport) void someFunction(void)
{
if ( (*pFooFunc)() )
{
... _same thing for objectsList_
}
}
App.exe :
LoadLibrary( "something.dll" );
setFoo = GetProcAddress(...);
setFoo(&foo);
我是对的还是有更优雅的方法来做这种事情？
这里的一些解决方案： DLL 需要访问其应用程序的符号< /a> 但我仍然对任何有关这种设计的讨论感兴趣。
谢谢
I have a DLL with a bunch of functions. So far, so good, that's what DLL are for.
But, some functions in my DLL need to call functions (or access data) from the application which loaded the DLL.
App.exe :
std::vector<SomeClass> objectsList;
bool foo(void)
{
...
}
LoadLibrary( "something.dll" );
something.dll :
__declspec(dllexport) void someFunction(void)
{
if ( foo() )
{
objectsList[2].someAttr = 1;
}
}
For what I know, my DLL code in not correct because the DLL cannot know foo or objectsList at linking. So, the only way I see is :
something.dll :
typedef bool fooType(void);
fooType* pFooFunc;
__declspec(dllexport) void setFoo(fooType* fooPtr)
{
pFooFunc = fooPtr;
}
__declspec(dllexport) void someFunction(void)
{
if ( (*pFooFunc)() )
{
... _same thing for objectsList_
}
}
App.exe :
LoadLibrary( "something.dll" );
setFoo = GetProcAddress(...);
setFoo(&foo);
Am I right or is there a more elegant way to do that kind of stuff ?
Some solutions here : a DLL need to access symbols of its application
But I am still interested in any discussion about this kind of design.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
常见的解决方案有两种：第一种是DLL使用
某种回调；第二个是将函数和
根和 DLL 之间共享的数据放入单独的 DLL 中
它自己的。
There are two common solutions: the first is for the DLL to use
some sort of callback; the second is to put the functions and
data shared between the root and the DLL(s) into a separate DLL
of its own.
通常，您会传递一个指向具有虚函数的对象的指针。这样，您就可以进行面向对象的设计和回调，只需一次函数调用，而不是每个导出函数调用一次。
Generally you'd pass a pointer to an object with virtual functions. That way you have object-oriented design and callbacks, with a single function call instead of one per exported function.
一般来说，回调是一个优雅的解决方案。
但听起来您的 DLL 依赖于一个特定的特定函数的存在和行为。如果是这种情况，那么您可能需要考虑应用程序和库之间是否有正确的划分。您的库是否将被多个应用程序使用？如果是，那么这个
foo()业务将如何运作？如果不是，那为什么它是一个DLL？In general, a callback is an elegant solution.
But it sounds like your DLL is relying on the existence and behaviour of one particular, specific function. If that is the case, then maybe you need to think about whether you have the correct split between your application and your library. Is your library going to be used by more than one application? If yes, then how is this
foo()business going to work? If no, then why is it a DLL?这是回调函数的经典设计模式。
只要您记录了库的使用者需要设置回调以及该回调函数应该执行的操作，就可以了。
That's a classic design pattern for a callback function.
As long as you document that consumer of your library needs to set a callback and what that callback function is supposed to do, this is fine.
实际上回调是最好的方法 ->显然，正如 Oli 提到的，依赖于外部实现的 DLL 可能是设计缺陷的标志。
就我个人而言，我会尝试让我的 DLL 不依赖于外部函数 ->除了在可执行文件中注册的回调之外......
Actually a callback is the best way of doing this -> obviously as Oli mentioned a DLL depending on an external implementation may be a sign of a flawed design.
Personally I'd try to have my DLL depend on no external functions -> apart maybe from a callback to register at the executeable…