Приветствую коллеги!

Среда разработки C++ Builder 5.

Такая проблема:
Довел проект до такого момента, когда он начинает терять устойчивость из-за своей грмоздкости и не до конца продуманных взаимосвязей. Отчасти виноват сам, готов признать. Сейчас решил выделить часть кода в отдельную dll-ку и работать с ней как с черным ящиком (на вход "А", на выходе "Б"). Это довольно гроздкий код и используется одновременно в двух исполняемых модулях. Статически включать его в состав одного и другого проектов неэффективно - дублирование большого объема кода. Хорошие решение - динамическая загрузка *.dll. Проблема в том, что этот код предтавляет собой класс (наследует TObject) и его нужно импортировать. Найти информацию о таком трюке мне не удалось. Поэтому не знаю, возможно ли такое вообще.

Почему динамическая линковка, а не статическая:
Импорт тестового класса из статически связанной библиотеки - прошел вполне успешно. Думаю, что и с рабочим сложности не возникнет. Однако в этом случае код будет загружен все время выполнения программы, чего хотелось бы избежать. К тому же из-за того что библиотеку приходится включать в состав проекта, опасаюсь, что если в будущем я захочу использовать ее в среде C++ Builder 6 или вовсе в Visual C, то поимею ряд проблем.

Буду благодарен за любое альтернативное решение.

Заранее благодарен.
С Уважением, Евгений.

Хмм... Еще не проверил, но вроде должно сработать - спасибо.

kolobok0 archez...... Найти информацию о таком трюке мне не удалось. Поэтому не знаю, возможно ли такое вообще. ......

а чаво искать то ?
ставите перед классом __declspec(dllexport) в описании дэлеле
и __declspec(dllimport) перед классом в ашнике который поставляете вместе с данной дэлеле...
для автоматизации мона начиркать следующее...

тогда класс будет выглядеть так (ашник)...

class бла_бла_API xru
{
public:
...........
...........
};

с тэмплейтами обьяву extern в данную комбинацию так же мона записать...

с уважением
(круглый)

Пояните уважаемый, плз, свою мысль.
Дело в том, что согласно http://bdn.borland.com/article/0,1410,20165,00.html
подобный фокус исполняется с родительским классом-интерфейсом, в котором токо виртуальные функции. А по Вашему аналогичный метод можно применить к конечному классу с объявленными методами и свойствами. Я еще не успел проверить сам, но хотелось бы знать подобный код работает или это умозрительное заключение. Если работает, то технология существенно упрощается - не нужно делать класс-интерфейс.

kolobok0 archez...... Найти информацию о таком трюке мне не удалось. Поэтому не знаю, возможно ли такое вообще. ......

а чаво искать то ?
ставите перед классом __declspec(dllexport) в описании дэлеле
и __declspec(dllimport) перед классом в ашнике который поставляете вместе с данной дэлеле...
для автоматизации мона начиркать следующее...

тогда класс будет выглядеть так (ашник)...

class бла_бла_API xru
{
public:
...........
...........
};

с тэмплейтами обьяву extern в данную комбинацию так же мона записать...

с уважением
(круглый)

Проверил Вашу технологию - результат:
На этапе компиляции ругается на конструктор и деструктор класса. Если их заремить, то компиляция проходит, но линковщик говорит:
Unresolver external '<function_name>' referenced from mana-mana.obj

Так что видимо, провильная технология именно через класс-интерфейс.

JibSkeartДа можно , классы юзать из динамических ДЛЛ.

допустим воть

http://bdn.borland.com/article/0,1410,20165,00.html

Да действительно, не считая пары багов в этом екзампле, методика верная для создания экземпляров класса. А как быть в случае, если в мой класс не подразумевает создания экземпляров, т.е. в нем все методы и свойств - статические.

kolobok0
1) у линковщика ищите нечто
Linker->Input->Additional Dependencis
и записываете тудысь нечто следующее...
путя\xru.lib
этот файл возьмите рядом с дэлеле Вашей хрю...оптимально -> нацелить прям путя к выходному каталогу дэлеле.


Прошу прощения за мой французкий, но либо я действительно чего-то крепко не понимаю либо одно из двух. Ваш метод один в один похож на статическую привязку dll. Главный признак - использование *.lib файла. Динамическое привязывание *.dll использование этого файла не предполагает. Способ динамической привязки подробно изложен в экзампле:
http://bdn.borland.com/article/0,1410,20165,00.html
который любезно предоставил JibSkeart.
Поправьте меня если я ошибаюсь.

C Уважением,
Евгений

kolobok0 ...Механизация COMа хороша...

Я абсолютно с Вами согласен. Но поскольку делаю первые шаги в области *.dll (раньше вполне обходился *.cpp библиотеками), то счел правильным вначале получше разобраться с этим вопросом, а потом, если увижу что требуемый функционал не достигнут, буду переводить код на COM или CORBA (еще не решил).

С Уважением,
Евгений.