DLL design : the DLL needs to access some of the application functions/data

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 wh开发者_开发百科ich 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

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.

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.

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…