Добрый всем день, делаю "систему" плагинов, то есть в папку кладешь файлы-плагины (dll-ки), затем программа запускается, подгружает dll-ки, и при необходимости пользуется услугами некоторых из них.

Проблема, в приложении-хосте (то что пользуется услугами длл-ок) каждая dll-ка завернута в класс, и уже внутри приложения все обращения к плагинам выглядят как обращение к экземплярам класса. Теперь для реализации полноценного келлбака из длл-ки, передаю в dll адрес функции которая играет роль келлбака, все работает идеально если эта функция, просто функция модуля, но когда пытаться передать её адрес когда она член класса, компилер пишет ошибку компиляции: Member function must be called or its address taken, ента проблема решается, если перед описанием этой функции поставить static, и передавать в длл адрес функции из this->executor (executor это функция келлбака), но получается, пришли к тому, от чего ушли 
А делать один для всех келлбак "не красиво"  Подскажите, у кого какие есть идеи, как определить адрес функции-члена класса?

А функции класса вызываются не совсем стандартным образом - просто по указателю ее не вызовешь, нужно еще указатель на объект передать. 

Кроме того, совершенно не обязательно, что указатель на функцию класса будет "просто" указателем (длиной 4 байта). Он, в зависимости от компилятора и многих других обстоятельств, может быть устроен по разному и иметь разную длину.

Самый правильный метод, ИМХО, - определить абстрактный интерфейс с нужными функциями, унаследовать от него класс в DLL и сделать экспортируемой одну функцию из DLL, которая вернет указатель на объект. И ничего больше не надо. Причем внутренности класса никому показывать не надо: с ним нужно работать через указатель на интерфейс (базовый класс). 
Так устроена модель COM, но нет никакой необходимости связываться именно с COM, всеми этими IUnknown и т.д., разве что хочешь интерфейс во вне выпустить. А если для "внутреннего" пользования - все сводится к тому, что я описала.
Если объект один, и он в DLL может быть объявлен как статический - то больше ни о чем заботиться не нужно. А если объектов могжет быть несколько, и они должны создаваться по запросу, то следует подумать также о их времени жизни и уничтожении. Здесь тоже возможно несколько вариантов.

Спасибо за "наводку" буду копать в этом направлении