Экзешник в качестве dll.

[Setuper]

В общем проблема вот в чём...

Написана программа. В программе есть некий класс Base.

Я пишу DLL-ку, которая содержит некий класс, который наследует класс Base.
В DLL-ке я подключаю заголовочный файл с классом Base, а линкер ругается на то, что не найдены реализации функций класса Base.

DLL-ку собираюсь подключать к экзешнику динамически.

Может ли екзешник при динамическом подключении DLL-ки каким-то образом предоставить ей реализации функций класса Base?

То есть вопрос в том как мне собрать DLL-ку?

[Джон]

В хорошем стиле было бы выгрузить класс Base в ещё одну dll, которой бы "пользовались" exe и другая dll.

[Setuper]

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

[Джон]

Если эта "другая" dll (назовём её 2.dll) тоже их использует, то - да. Это позволит использовать 2.dll, не только с этим ехе.

Короче надо хорошенько продумать архитектуру. Навскидку, возможны два варианта:

1.

                        exe1   <---  2.dll <----  Base.dll

2.     

                         exe1 <------------   2.dll
                            ^                          ^
                             |                           |
                             ----- Base.dll -------


зы Чтоже это за экзешник такой, что ВСЯ! его функциональность требуется библиотеке, от которой он зависит?   
ИМХО кто-то явно чего-то не додумал.

зы зы хорошо, что Димка этого не видит, или видит, но молчит. 

[Sel]

Offtopic:

Алексей1153++, не флудить.

Поставлю в угол.

[Setuper]

Спасибо всем.
Проблема решилась использованием абстрактных классов.

[Джон]

Бред.

[Setuper]

Почему же бред?
Я просто реализовывал систему плагинов для программы.

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

Почему же вы назвали это бредом?

[Алексей++]

Setuper, а когда у тебя компилятор ругается, если ты *.h файлы или классы в них не в том порядке разместил, ты тоже на виртуальностях выезжаешь ? Зачем усложнять, когда этого не требуется ?

[Джон]

Почему же вы назвали это бредом?

исходная формулировка задачи + решение в виде абстрактных классов = бред

[Setuper]

Setuper, а когда у тебя компилятор ругается, если ты *.h файлы или классы в них не в том порядке разместил, ты тоже на виртуальностях выезжаешь ?

Тут дело то не в порядке!

Зачем усложнять, когда этого не требуется ?

Ну а как проще то сделать? Вроде сделал проще некуда.

исходная формулировка задачи + решение в виде абстрактных классов = бред

Исходная формулировка задачи была в компиляции dll-ки, которая использовала бы функции экзешника.
Вы же предлагали тупо запихнуть всю реализацию проекта в dll, что наверное является большим бредом, чем использование виртуальных классов.

[Джон]

Setuper, внимательно вникаем в суть написаного самим же собой:

Написана программа. В программе есть некий класс Base.
Я пишу DLL-ку, которая содержит некий класс, который наследует класс Base.

Где же "ВСЯ РЕАЛИЗАЦИЯ"? Я вижу ТОЛЬКО ОДИН родительский класс, который необходимо вытащить из exe и разшарить, для совместного использования в обоих модулях. Возражения?

Идём дальше. После:

Получается что нужно весь экзешник помещать в dll.

я подчёркиваю, в контексте стоит "ВЕСЬ ЭКЗЕШНИК" и не я это написал, но как-то это автоматически в первой части было не очень очевидно - один класс = вся реализация, кривая архитектура становится очевидной. Или это нормально и логично делать исполняемый модуль зависимым от библиотеки, которая требует ВСЮ РЕАЛИЗАЦИЮ этого модуля? Внимательно вчитываемся. Офигивание оставляю на домашнее задание.

Ну и решение такой кривизны концепции в виде:

Проблема решилась использованием абстрактных классов.

я иначе как бредом назвать не могу. Ибо ООП методы могут помочь программеру улучшить свой код, сделать его более изящным, но никак не исправят кривизну и непродуманность архитектуры взаимодействия модулей. А если экзешник и библиотека вобще без ООП созданы? Как тогда будет решаться эта круговая порука? Или без ООП нельзя программировать? Алгоритм, если это хороший алгоритм, должен работать в обоих случаях. А иначе это уже не искусство, а ремесло. Сделал а лишь бы как, работает и ладно. Подогнал под ответ в 80% случаев, а на остальное наплевать. Тем паче, что всегда можно на операционку свалить, мы то ведь сами белые и пушистые.

А если же вопрос изначально подразумевал под собой нечто другое, то тогда и формулировать его надо было иначе. Золотое правило: каков вопрос, такой и ответ.

В озвученой формулировке я своё мнение высказал. А каждый вправе поступать так как считает нужным согласно своей опытности и уровня образованности, а на бессмысленные дискуссии у меня нет, не было и не будет времени.