Дизайн DLL: DLL должен иметь доступ к некоторым функциям / данным приложения

Question

У меня есть DLL с кучей функций. Пока все хорошо, для этого и нужна DLL. Но некоторые функции в моей DLL должны вызывать функции (или обращаться к данным) из приложения, которое загрузило DLL.

App.exe:

std::vector<SomeClass> objectsList;
bool foo(void)
{
    ...
}
LoadLibrary( "something.dll" );  

что-то.dll:

__declspec(dllexport) void someFunction(void)
{
    if ( foo() )
    {
        objectsList[2].someAttr = 1;
    }
}

Насколько я знаю, мой код DLL неверен, потому что DLL не может знать foo или objectsList при связывании. Итак, я вижу только так:

что-то.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 должна получить доступ к символам своего приложения Но я все еще заинтересован в любом обсуждении этого вида дизайна.

Спасибо

Answer 1

Существует два распространенных решения: во-первых, DLL использует своего рода обратный вызов;второе - поместить функции и данные, совместно используемые корнем и DLL, в отдельную отдельную DLL.

Answer 2

Обычно вы передаете указатель на объект с виртуальными функциями. Таким образом, у вас есть объектно-ориентированный дизайн и обратные вызовы, с одним вызовом функции вместо одного на экспортируемую функцию.

Answer 3

На самом деле обратный вызов - лучший способ сделать это -> очевидно, как Оли упомянул, что DLL в зависимости от внешней реализации может быть признаком некорректного проекта.не зависит от внешних функций -> кроме, может быть, от обратного вызова для регистрации в исполняемом ...

Answer 4

Это классический шаблон проектирования для функции обратного вызова.

Пока вы документируете, что потребитель вашей библиотеки должен установить обратный вызов и что должна делать эта функция обратного вызова, это нормально.

Answer 5

Как правило, обратный вызов является элегантным решением.

Но похоже, что ваша DLL полагается на существование и поведение одной конкретной, конкретной функции. Если это так, то, возможно, вам нужно подумать о том, правильно ли вы разбили приложение и библиотеку. Ваша библиотека будет использоваться более чем одним приложением? Если да, то как этот бизнес будет работать? Если нет, то почему это DLL?