Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Не явный экспорт наследника их DLL  (Прочитано 6421 раз)
0 Пользователей и 1 Гость смотрят эту тему.
PSD
Главный специалист

ru
Offline Offline
Пол: Мужской

« : 20-06-2006 11:10 » 

Пытаюсь писать плагины.

Идея: в папке лежет произвольное число библиотек содержащих в себе реализации протоколов доступа к устроствам.

С точки зрения исполняемого модуля монипуляции с устроством происходят посредством класса  СDevice в котром реализованы

class СDevice
{
int m_id_type_device;
....
virtual Init(void);
}
//костр1
class СDeviceKm5 : public  СDevice
{
virtual Init(void);
}
//костр2
class СDeviceKm6 : public  СDevice
{
virtual Init(void);
}
 
соотвественно в исполняемом модуле имеется массив указателей

СDevice * b[10];
...

b[0]=(СDevice *)new  СDeviceKm5 ;
b[0]->m_id_type_device=0;
b[1]=(СDevice *)new  СDeviceKm6 ;
b[1]->m_id_type_device=1;

for(i=0;i<10;i++)
{
b->Init();
}

///



Все хорошо но есть один раб для внесения изменей  или добовления новго типа нужно пресобирать весь проект.

Хочу вынести конструкции //костр2 //костр1 в отдельные dll

что бы  загрузка и работа виглядели примерно так
typedef  MYPROC ..... /// не знаю как преобразовать прототип функции в это опредление

for(i=0;i<10;i++)
{ MYPROC fn;
....
hM=LoadLibrary(lpsName);
fn = (MYPROC)GetProcAddress(hM,"GetDeviceModule")
b=fn() ;
}

Проблема в том что ни как не могу сообразить 

1) как прототип   СDevice *  GetDeviceModule (void );  представить
в виде 
typedef VOID (*MYPROC)(LPTSTR);  //взято из примера MSDN там проторит VOID myFN (LPTSTR str);

2)  как превельно описать наследникак  СDevice  в ДЛЛ чтобы  можно было сделать в  так

СDevice *  GetDeviceModule (void )
{
return (СDevice *)new  СDeviceKm5 ;
}


Простите за сумбур с утра уже туплю....если можно дайте простенький пример с такми экспортом наслдника...



 
Записан

Да да нет нет все остальное от лукавого.
Finch
Спокойный
Администратор

il
Offline Offline
Пол: Мужской
Пролетал мимо


« Ответ #1 : 20-06-2006 12:57 » 

PSD, В прошлом году Громом поднималась похожая тема. А теперь по сушеству вопроса Улыбаюсь

Прототип объявляеш так
Код:
typedef СDevice *  (__stdcall *TGetDeviceModule) (void );

В Dll стандартизировано применение типа вызова функции stdcall. Хотя есть даже стандартные библиотеки с другим типом вызова.   

Шаблон построения твоей ДЛЛ

CPP Файл
Код:
#define DLLLOADAPI extern "C" __declspec(dllexport)
#include "CDeviceDLL.h"

СDevice *  GetDeviceModule (void )
{
return (СDevice *)new  СDeviceKm5 ;
}


BOOL WINAPI DllMain(HINSTANCE hinst, unsigned long reason, void*)
{

switch( reason )
   {
case DLL_PROCESS_ATTACH:
           // Initialize once for each new process.
           // Return FALSE to fail DLL load.
           break;

      case DLL_THREAD_ATTACH:
         // Do thread-specific initialization.
            break;

      case DLL_THREAD_DETACH:
         // Do thread-specific cleanup.
            break;

      case DLL_PROCESS_DETACH:

         // Perform any necessary cleanup.
            break;
    }
    return TRUE;  // Successful DLL_PROCESS_ATTACH.
}

h файл
Код:
#ifndef DLLLOADAPI
#define DLLLOADAPI extern "C" __declspec(dllimport)
#endif
#include <windows.h>
//-------------------------------------------------------------------
DLLLOADAPI СDevice * __stdcall GetDeviceModule (void );
//-------------------------------------------------------------------

def файл
Код:
LIBRARY     CDeviceDLL

DESCRIPTION 'Device DLL'

EXPORTS
           GetDeviceModule                      @1

Все три файла вставляеш в проект Dll .
« Последнее редактирование: 19-12-2007 18:27 от Алексей1153++ » Записан

Не будите спашяго дракона.
             Джаффар (Коша)
PSD
Главный специалист

ru
Offline Offline
Пол: Мужской

« Ответ #2 : 21-06-2006 04:01 » 

(Громовскую тему видел ... тогда не понял нафига это надо теперь понял...)

А как быть с  СDeviceKm5 ?   Его реализация должна быть в ДЛЛ... а 
СDevice я так понимаю должен быть и в ДЛЛ и в основном проекте. Но при этом получится что методы класса СDevice будут линкованы в проект дважды 1раз статически пот сборке проекта второй раз динами чески при подключении ДЛЛ.... Не произойдет путаницы с переопреджелнием виртуальных функций?
Записан

Да да нет нет все остальное от лукавого.
Finch
Спокойный
Администратор

il
Offline Offline
Пол: Мужской
Пролетал мимо


« Ответ #3 : 21-06-2006 11:58 » 

PSD, Выбери путь подключения библиотеки. Если ты подключаеш динамически, то ничего не нужно линковать к основному проекту. Просто действуеш по описанному тобой сценарию. А описание объекта естественно нужно делать в проекте твоей ДЛЛ.
Записан

Не будите спашяго дракона.
             Джаффар (Коша)
PSD
Главный специалист

ru
Offline Offline
Пол: Мужской

« Ответ #4 : 21-06-2006 12:17 » new

Всеравно не догоняю... у меня два класса родитель и наследник,
о существовании родителя должны знатьи и исполняемы модуль и библиотека, внем прописан базовый набор свойств и общие для всех потомков набор своств.

При этом мы имеем (по стандарту мялкомягких 2 файла) заголовочный и тело,

проблемы включить эти два фала в оба проекта нет, но тогда получается что
тело класс предка  СDevice ббудет иметь 2 реализации в исполняемом модуле и библиотеке... и по идее статические переменных тоже будет 2 одна в исполняемом модуле вторая в библиотеке ?  Я  прав?


(Хм ... что то мне начало казаться что язабиваю гвозди пасатижами ... помоему суда просится интерфейс.... а можно использовать интерфес без СОМ технологии просто как средство доступа к классу? )

 




 
 

   
Записан

Да да нет нет все остальное от лукавого.
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines