Если в dll-модуле у меня описан некий класс.
Как к нему добраться при явном свзывании (т.е. создать объект этого класса) и как для этого его в dll надо правльно объявлять.

Через __declspec(dllexport) и __declspec(dllimport)
В dll экспорт, в программе импорт

*.Н

Код

class __declspec(dllimport) CMeasData { ... public: ... };

Только __declspec(dllimport) заменить макросом, чтоб в ДЛЛ это был экспорт, а в программе импорт

Спасибо, но тут еще тиакая проблема, если функцию я получаю через
GetProcAdress, как мне то же самое сделать для имени класса?
Как таким же образом создать объект?

Цитата

функцию я получаю через GetProcAdress, как мне то же самое сделать для имени класса

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

Код

#include "myClass.h" // здесь только интерфейс класса, избегайте реализации ... myClass * (__cdecl *Proc)(); // например такой указатель на ф-цию HANDLE hDLL= LoadLibrary("SomeLib"); // грузим библиотеку Proc myProc= (Proc)::GetProcAddress(hDLL, "SomeName"); myClass *myObj= myProc(); if(myObj)    myObj->Foo(); // весь public интерфейс к вашим услугам ...

ЗЫ: Отсюда до идеи COM уже совсем недалеко...

Хотя, ваще-то попадалась мне какая-то статейка, где рассматривалось как можно с помощью GetProcAddress получить адрес конструктора класса... Вот не помню, где это я ее читал.
Но это выёживание. Будьте проще и к вам потянутся люди.

Спасибо.
А если без подключения .h файла, то как я поняла, без com никуда?

Цитата

А если без подключения .h файла, то как я поняла, без com никуда

Без объявления типа переменной(объект - это тоже переменная, тип к-рой определен пользователем) вообще никуда! Переменную неопределенного типа ни создать нельзя, ни ссылку/указатель получить. Исключение - указатель на тип void *. Но указатель void * - это не то, что нам нужно.

Для доступа к методам класса нужно знать его интерфейс, т.е. знать какие ф-ции-члены там имеются и как объявлены (о прямом доступе к атрибутам класса - вообще речи нет, т.к. это плохой стиль, нарушающий принцип инкапсуляции). Поэтому, этот интерфейс надо откуда-то получить. Традиционно объявления классов помещаются в заголовочные файлы. Можно дать объявление класса и в cpp-файле, если это реализация нек-рого впомогательного класса, объекты к-рого за пределами реализации в данном cpp-файле иметь не требуется.

Для COM-классов можно указать, чтобы компилер сгенерил заголовочный файл, содержащий объявление требуемого класса, используя его(класса) type library. Например, директива

Код

#import <msxml4.dll> raw_interfaces_only

требует используя содержимое библиотеки msxml4.dll сгенерить заголовочный файл с объявлениями соотв. COM-классов.

Nastya, а почему именно явное связывание? Есть ведь такая вещь как отложенная загрузка (правда если на BCB то там какой фишки нет , придеться ручками писать, ну это тоже не проблема -> здесь)...

Код

#include "myClass.h" // здесь только интерфейс класса, избегайте реализации ... myClass * (__cdecl *Proc)(); // например такой указатель на ф-цию HANDLE hDLL= LoadLibrary("SomeLib"); // грузим библиотеку Proc myProc= (Proc)::GetProcAddress(hDLL, "SomeName"); myClass *myObj= myProc(); if(myObj)    myObj->Foo(); // весь public интерфейс к вашим услугам ...

Кстати интересно, как при таком подходе деструктор объекта вызывается...???

Статья про которую говорил Fire-Plug находиться здесь

Это сообщение отредактировал(а) np9mi7 - 10.4.2005, 20:17

Цитата(np9mi7 @ 10.4.2005, 10:41)

Кстати интересно, как при таком подходе деструктор объекта вызывается...???

Тут уместно применить принцип: "Я тебя породил, я тебя и убью". Т.е., если объект создается в коде DLL, то и уничтожаться он должен там же.
Вариантов реализации можно предложить несколько.
1) Динамический объект помещается, например, в авто-указатель, к-рый жив покуда DLL не выгружена.
2) Можно удалять объект по требованию. Тогда нужно будет добавить в DLL экспортируемую ф-цию для уничтожения объекта, передавая в кач-ве параметра его адрес. В DLL хранить объект в нек-ром контейнере, где он разыскивается с целю приведения приговора в исполнение.
3) Можно 2) реализовать путем заимствования идеи COM в плане подсчета ссылок. Тогда лучше возвращать указатель не на сам объект, а объект типа COM-указателя для целевого класса, для к-рого нужно будет добавить методы аналогичные AddREf() и Release(). А в DLL реализовать механизм для хранения и удаления объекта, если к-во его ссылок = 0.

Цитата

1) Динамический объект помещается, например, в авто-указатель, к-рый жив покуда DLL не выгружена.

, не катит, адреса деструктора у тебя нет;

Цитата

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

, пахнет чем то не хорошим, тебе так ни кажеться?

Цитата

3) Можно 2) реализовать путем заимствования идеи COM в плане подсчета ссылок. Тогда лучше возвращать указатель не на сам объект, а объект типа COM-указателя для целевого класса, для к-рого нужно будет добавить методы аналогичные AddREf() и Release(). А в DLL реализовать механизм для хранения и удаления объекта, если к-во его ссылок = 0.

, может сразу com объект и все?

Мне кажеться тут лучше всего отложенная загрузка.

Это сообщение отредактировал(а) np9mi7 - 12.4.2005, 08:06

Цитата(np9mi7 @ 12.4.2005, 08:05)

не катит, адреса деструктора у тебя нет;

Это-то в коде, где реализован конкретный класс, т.е. в коде DLL? Не смешите меня.

Цитата(np9mi7 @ 12.4.2005, 08:05)

Цитата 2) Можно удалять объект по требованию. Тогда нужно будет добавить в DLL экспортируемую ф-цию для уничтожения объекта, передавая в кач-ве параметра его адрес. В DLL хранить объект в нек-ром контейнере, где он разыскивается с целю приведения приговора в исполнение. , пахнет чем то не хорошим, тебе так ни кажеться?

Ничем не хуже, чем delete myObj. "не хорошим" - явл. только ситуация, в к-рой следует соблюдать договоренности, а именно, удалять обьект с помощью спец. экспортируемой ф-ции. Но и указатель на обьект был получен также с помощью другой спец. ф-ции, а не через new

Цитата

, может сразу com объект и все?

Конечно можно, если охота для частной задачи писать реализацию обязательной части интерфейса и возиться с его регистрацией.

Цитата

1) Динамический объект помещается, например, в авто-указатель, к-рый жив покуда DLL не выгружена

Цитата

Это-то в коде, где реализован конкретный класс, т.е. в коде DLL? Не смешите меня.

, задам один вопрос: где smatr pointer?

Цитата(np9mi7 @ 13.4.2005, 10:26)

задам один вопрос: где smatr pointer?

В коде DLL, конечно.

ну, тогда твоему ptr нужен адрес деструктора объекта... Нет?

Вообще, экспортируемые классы суть набор экспортируемых ими методов куда входят и конструкторы и деструкторы. Кажется вполне возможным написать обертку, которая будет грузить библиотеку с помощью LoadLibrary и вызывать методы через GetProcAddress (включая конструкторы и деструкторы).