Экспорт / импорт (dll) функций из класса

← →
BiN © (2006-06-29 15:00) [120]

> Пусик © (29.06.06 14:43) [114]

Главное, что тебе пытаются донести, это то, что экспортировать методы объекта - плохо.
Использовать объекты при реализации экспортируемых функций в DLL - хорошо.
Плохо, потому что изобретение велосипеда (COM\DCOM) - это плохо
Хорошо, потому что ООП - это хорошо.
-)

← →
Fay © (2006-06-29 15:05) [121]

2 Игорь Шевченко © (29.06.06 15:00) [119]
> Если в качестве параметров функций передаются объекты
Это не совсем внутри.

← →
Игорь Шевченко © (2006-06-29 15:07) [122]

Fay © (29.06.06 15:05) [121]

> Это не совсем внутри.

Ты наверное фразу "в больинстве случаев не приводит к проблемам" забыл прочитать, да ? :)

← →
Шпиён (2006-06-29 15:07) [123]

> BiN © (29.06.06 15:00) [120]

> Использовать объекты при реализации экспортируемых функций
> в DLL - хорошо.

Ничего подобного тут донести не пытаются -) LVT проповедует мысль, что объекты в dll - это всегда нехорошо, потому как излишество и умножение сущностей -)))

← →
Пусик © (2006-06-29 15:19) [124]

> BiN © (29.06.06 15:00) [120]
>
> > Пусик © (29.06.06 14:43) [114]
>
>
> Главное, что тебе пытаются донести, это то, что экспортировать
> методы объекта - плохо.

До меня этого не надо доносить.
Разговор не об экспорте классов, а об использовании их внутри DLL

← →
Игорь Шевченко © (2006-06-29 15:23) [125]

> Разговор не об экспорте классов, а об использовании их внутри
> DLL

Цитата из поста [40]

"Допустим даже, что у нас есть доводы за dll.
Как, собс-но, мы должны применить ООП?
Видимо:
1. Создать объект
2. Заполнить его поля некоторыми простых типами,
переданными из хоста.
3. Сделать некоторые пассы.
4. Вернуть хосту нужные простые типы из полей.
5. Разрушить объект.

Налицо некоторые overheads. Т.е., все это совершенно спокойно
можно свести к неким преобразованиям простых типов,
без мучительных раздумий, как уследить за распределенной
в длл памяти, что будет, если будет повторный вызов в промежутке
между 1 - 6 и т.д."

У тебя есть другие варианты использования объектов ?
В студию.

← →
BiN © (2006-06-29 15:25) [126]

> Шпиён (29.06.06 15:07) [123]
> LVT проповедует мысль, что объекты в dll - это всегда нехорошо, потому как излишество и умножение сущностей

> Пусик © (29.06.06 15:19) [124]

Леонид говорит о нецелесообразности использования классов в DLL - и говорит это в контексте сабжа, в контексте импорта/экспорта. Думаю, вы его просто неправильно поняли.

← →
Fay © (2006-06-29 15:31) [127]

2 BiN © (29.06.06 15:25) [126]
> говорит это в контексте сабжа, в контексте импорта/экспорта
Не поверю в это, пока он сам этого не скажет.
После чего начну сосневаться 8)

> Думаю, вы его просто неправильно поняли.
Вот и Шевченко Игорь так думает (похоже)... Но вы оба ошибаетесь.

← →
Шпиён (2006-06-29 15:34) [128]

> BiN © (29.06.06 15:25) [126]

[40] [42] [43] [56] [63]

← →
Romkin © (2006-06-29 15:41) [129]

Дык! Юзверь вызывает функцию, внутре у ей
1. Создается объект
2. Заполняются его поля данными входных параметров
3. Что-то делается.
4. Заполняются выходные параметры данными полей класса.
5. Разрушается объект.
Это делать рекомендуется, как уже сказано, когда есть уже объект нужной функциональности, и при этом объемный.
Это - случай, о котором говорит LVT. Понятно, что можно просто вырезать код выполняемых методов объекта, вставить его в набор функций и обойтись без работы с объектом.

Насчет же использования объектов из dll есть хороший пример прямо перед глазами, Qt library. Delphi 6 и выше. Дело в том, что библиотека Qt - объектная, предоставляющая классы C++. Для использования в Delphi над ней сделали обертку, тоже dll, экспортировав всю работу с классами в виде функций. Затем в CLX сделали обертку над этой dll в виде набора классов. Прикольно? Фактически для CLX дело выглядит так, что она работает с классами в dll через вызов обычных функций этой dll.

Третий путь, как я уже говорил, использование интерфейсов - там уже даже не ООП, а компонент-ориентированное программирование. Кстати, не считайте, что это невыгодно: время на вызов метода класса в dll через VTable вполне сравнимо с простым вызовом метода обычного класса.

Четвертый путь - использование различных менеджеров объектов, SOAP, сервера приложений и тд. Но это уже не относится к теме.

Вот, пожалуй, и все случаи. Выбирайте, что больше нравится.

← →
saxon (2006-06-29 15:51) [130]

> Romkin © (29.06.06 15:41) [129]

Жму руку! :)

← →
BiN © (2006-06-29 15:54) [131]

> Шпиён (29.06.06 15:34) [128]
>
>
> > BiN © (29.06.06 15:25) [126]
>
> [40] [42] [43] [56] [63]

Мдя, перечитал еще раз. Извиняюсь.
Следуя логике этих постов, ООП вообще не имеет смысла, т.к. всё можно реализовать и без него.

← →
Шпиён (2006-06-29 16:01) [132]

> Это делать рекомендуется, как уже сказано, когда есть уже
> объект нужной функциональности, и при этом объемный.
> Это - случай, о котором говорит LVT.

Об этом случае сказал я. LVT назвал это "натяжкой", но в [63] переименовал в "здоровый компромисс". И то не без сарказма. ([46] [54] [63]).
Возможно, я сам виновник этого сарказма, потому как более чёткая формулировка ситуации [115] приведена много позже (в пылу дискуссии умные фразы не очень хорошо получаются).

← →
Шпиён (2006-06-29 16:04) [133]

> Понятно, что можно просто вырезать код выполняемых методов
> объекта, вставить его в набор функций и обойтись без работы
> с объектом.

Особенно весело это делать, когда у объекта туева хуча унаследованных методов плюс еще внутри объект агрегирован -)

← →
Игорь Шевченко © (2006-06-29 16:06) [134]

BiN © (29.06.06 15:54) [131]

> Следуя логике этих постов, ООП вообще не имеет смысла, т.
> к. всё можно реализовать и без него.

ООП имеет смысл. Там, где можно экспортировать классы, например, в случае с разбивкой приложения на хост и дополнительные модули.

← →
Игорь Шевченко © (2006-06-29 16:08) [135]

Шпиён (29.06.06 16:04) [133]

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

← →
Romkin © (2006-06-29 16:10) [136]

Шпиён (29.06.06 16:04) [133] Я говорил теоретически :) Конечно, удобнее просто пользовать. А вот писать свой собственный объект для случая №1 - целесообразность сомнительна. Если уж нужно - есть третий путь :)))
Недавно сосед с моей помощью написал ActiveX lib для доступа к данным нашего сервера приложений, фактически - небольшую обертку над TDataset. И порядок: объект с агрегацией, из 1С и офиса работает.

← →
BiN © (2006-06-29 16:12) [137]

> Игорь Шевченко © (29.06.06 16:06) [134]
>
>
> ООП имеет смысл. Там, где можно экспортировать классы, например,
> в случае с разбивкой приложения на хост и дополнительные
> модули.

А зачем? Можно же и без классов, и сущности не умножаются. (зато умножается головная боль)

← →
Fay © (2006-06-29 16:12) [138]

2 Игорь Шевченко © (29.06.06 16:08) [135]
А ещё можно вообразить, что длл уже есть. Ваще кайф.

← →
Шпиён (2006-06-29 16:21) [139]

> Romkin © (29.06.06 16:10) [136]

> А вот писать свой собственный
> объект для случая №1 - целесообразность сомнительна.

Так я с этим и не спорю -) Даже более того - согласен на 100%.

← →
Игорь Шевченко © (2006-06-29 16:22) [140]

BiN © (29.06.06 16:12) [137]

> А зачем? Можно же и без классов, и сущности не умножаются.
> (зато умножается головная боль)

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

← →
Шпиён (2006-06-29 16:32) [141]

>Игорь Шевченко © (29.06.06 16:08) [135]
Вообразить можно всё что угодно. А работать придётся с тем, что есть на самом деле.
<offtopic>
вообрази, что у тебя дача на Канарах есть. Наслаждайся -)
</offtopic>

← →
Игорь Шевченко © (2006-06-29 16:33) [142]

Шпиён (29.06.06 16:32) [141]

На каждую необходимую DLL готовых объектов не напасешься.

← →
Шпиён (2006-06-29 16:37) [143]

> Игорь Шевченко © (29.06.06 16:33) [142]

А я где-нибудь утверждал, что это надо делать в каждой необходимой dll?

← →
Игорь Шевченко © (2006-06-29 16:41) [144]

Шпиён (29.06.06 16:37) [143]

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

← →
Шпиён (2006-06-29 16:44) [145]

> Игорь Шевченко © (29.06.06 16:41) [144]

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

← →
Romkin © (2006-06-29 16:56) [146]

Многоуважаемые господа, позвольте мне, как скромному читателю Ваших реплик, нижайше поинтересоваться Вашими планами и замыслами дальнейшего развития сего, без сомнения будь сказано, наизамечательнейшего диалога?
:-Р

← →
Пусик © (2006-06-29 17:12) [147]

> Romkin © (29.06.06 16:56) [146]
> Многоуважаемые господа, позвольте мне, как скромному читателю
> Ваших реплик, нижайше поинтересоваться Вашими планами и
> замыслами дальнейшего развития сего, без сомнения будь сказано,
> наизамечательнейшего диалога?:-Р

Вот я и вернулась ;-)

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

Следуя логике Игоря Шевченко, можно подумать, что следует вообще отказаться от использования ООП, так как это увеличивает количество сущностей. Но ведь процесс программирования ценен не сам по себе, а лишь как средство для решения различных прикладных и системных задач.
С точки зрения системмных задач можно согласиться с нектороыми утверждениями и отказом от ООП во многих случаях. Но с точки зрения прикладного программирования совершенно неопрадан отказ от ООП, как средства быстрой разработки, масштабируемости приложений и удобства дальнейшего сопровождения.
При решении любой заачи необходимо руководствоваться принципом целесообразности, а не личными тараканами в голове(что тоже неплохо иногда, но тараканы-то - личные, и не стоит их выносить в общество).

← →
Игорь Шевченко © (2006-06-29 17:30) [148]

Пусик © (29.06.06 17:12) [147]

> Следуя логике Игоря Шевченко, можно подумать, что следует
> вообще отказаться от использования ООП, так как это увеличивает
> количество сущностей.

[140] до полного и окончательного просветления

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

" - Мудро. Руководствуйтесь этим принципом и впредь. Благодарю вас за
внимание, Штирлиц." (с) Альтернатива

Пусик © (29.06.06 17:12) [147]
[129] и [136] Мне казалось, что вопрос исчерпан, а тут опять.

> совершенно неопрадан отказ от ООП, как средства быстрой разработки, масштабируемости приложений и удобства дальнейшего сопровождения

В посте 129 я описал способы организации объектов в dll. Какой способ ты предлагаешь?

> Игорь Шевченко © (29.06.06 17:30) [148]
> Пусик © (29.06.06 17:12) [147] > Следуя логике Игоря Шевченко,
> можно подумать, что следует > вообще отказаться от использования
> ООП, так как это увеличивает > количество сущностей.[140]
> до полного и окончательного просветления

Ешьте сами с волосами. И просветляйтесь.

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

> Впрочем, есть примеры, когда ООП не приносит никакого выигрыша.
>

Вот именно. Существует не очень большой круг задач, где ООП не приносит выигрыша. Но в подавляющем большинстве случаев (мы же не говорим о программе "Здравствуй, Мир!") ООП является большим подспорьем программисту.
------
Т.е., как я поняла, позиция уже немного поменялась? Если раньше говорилось о том, что надо всячески избегать использования ООП, так как это множит сущности, то теперь оврится лишь об исключительных случаях, когда применение ООП не рекомендуется?

> " - Мудро. Руководствуйтесь этим принципом и впредь.

Очень любезно с твоей стороны понять и принять эту точку зрения.

> Romkin © (29.06.06 17:30) [149]
> Пусик © (29.06.06 17:12) [147] [129] и [136] Мне казалось,
> что вопрос исчерпан, а тут опять.> совершенно неопрадан
> отказ от ООП, как средства быстрой разработки, масштабируемости
> приложений и удобства дальнейшего сопровожденияВ посте 129
> я описал способы организации объектов в dll. Какой способ
> ты предлагаешь?

Ты считаешь, что этими вариантами применение ООП исчерпывается?

Не согласна. Навскидку предложу еще один вариант(а лучше пример):

Задача - прием и обработка информации, приходящей по каналам связи.
Данные приходят в различных форматах, для передачи используются различные протоколы. После обработки данные помещаются в файлы на диск, в основное приложение передается только статистическая информация.
Обработка файлов должна проводиться в режиме 24/7.

Для реализации используется ООП.
<родительский класс-протокол>-MainDLL-->
<Дочерний класс-протокол1>-Prot1DLL
<Дочерний класс-протокол2>-Prot2DLL
...
<Дочерний класс-протоколN>-ProtNDLL

Периодически список обрабатываемых протоколов изменяется - одни устаревают и удаляются, новые появляются.

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

Небольшой нюанс: как в родительском, так и в дочерних классах реализован достаточно большой объем обработки.
-------------------
Вот такая простая задача.
Возможен такой вариант? Возможен.

Та же задача может быть реализована другими способами? Может.

А смысл использовать другой способ? Почему не этот? Из-за дурацкой мысли, что ООП в DLL - это плохо?

То есть, одна dll - один класс? Я спрашивал именно о способе общения с классом в библиотеке. Как он происходит в данном случае? По второму способу? Или классы передаются за пределы dll?

Мне кажется (м.б. только мне), в [150] приведён очень неудачный (на редкость) пример. Ну зачем делать протокол классом?

> Пусик © (29.06.06 18:23) [150]

> Т.е., как я поняла, позиция уже немного поменялась? Если
> раньше говорилось о том, что надо всячески избегать использования
> ООП, так как это множит сущности, то теперь оврится лишь
> об исключительных случаях, когда применение ООП не рекомендуется?

Дык, конечно, речь об этих (исключительных) случаях -
об использовании ООП в dll.

Хочется дельфийского ООП - пиши все в экзешник.
Хочется dll - извольте-с опуститься к простым типам-с.
Хочется чего-то еще - юзайте COM.

Ну, и хватит брызгать слюной, здесь собираются
вполне, IMHO, серьезные люди.

--
Regards, LVT.

> Romkin © (29.06.06 18:30) [151]
> То есть, одна dll - один класс? Я спрашивал именно о способе
> общения с классом в библиотеке. Как он происходит в данном
> случае? По второму способу? Или классы передаются за пределы
> dll?

Способ общения:

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

Методы линковки - неважные частности в данном случае.

> Fay © (29.06.06 18:37) [152]
> Мне кажется (м.б. только мне), в [150] приведён очень неудачный
> (на редкость) пример. Ну зачем делать протокол классом?

Ну замени слово "протокол" на "тип файла"?

> Leonid Troyanovsky © (29.06.06 18:53) [153]
> Ну, и хватит брызгать слюной, здесь
> собираютсявполне, IMHO, серьезные люди.

Не похоже.

2 Пусик © (29.06.06 18:56) [154]
> Ну замени слово "протокол" на "тип файла"?
Заменил. Те же яйца.
Правда, я не имею ни малейшего представления об экспортируемых функциях.
А ваще, мне пофиг.

> Fay © (29.06.06 15:31) [127]

> > говорит это в контексте сабжа, в контексте импорта/экспорта
> Не поверю в это, пока он сам этого не скажет.

Правильно, не верь :)

Что есть dll? PE, который вписывается в запущенный процесс.
Его назначение - загружаться и выгружаться динамически.
в некоторые, определенные кодом экзешника процесса моменты.
Заметим, что моменты этих вызовов могут определяться
неким хостом, которому глубоко безразлична дельфийская
объектная модель. Т.е., ему фиолетова правильная инициализация,
правильное использование и разрушение неких объектов и
их последовательность.
Да и как он может знать о правильности, если оная модель
ему недоступна? Значит, весь труд по правильному применению
нутренных объектов лежит на совести разработчика.

Предположим, что все 6 шагов уложились в один внешний вызов.
В этом случае, как уже отмечалось, достаточно скопировать
(с некотрыми преобразованиями) код вызываемых методов в
обычные процедуры (и чего там такого сверхестественного
могут делать эти методы).

Т.е., в данном случае достаточно убрать накладные
расходы, связанные с самими объектами.
Вполне посильная задача с вполне приемлемым результатом.
Кстати, и бонус возможен - т.е., за счет использования только
простых типов область применения может стать даже шире,
чем у исходного объекта.

Случай второй: для экономии мы создадими объект
один раз, а уж пользовать будем его во все дыры.
Т.е., между 1 и 6 возможен зазор.
Ну, а тогда у нас новые проблемы, нужна (необъектная)
ссылка на объект, определяемая при его создании,
хранящеся не только у хоста, но и в некотором
внутреннем списке, с помощью которого мы
будем рассчитывать корректно оные объекты
освободить, если вдруг DLL_PROCESS_DETACH.

Но, маленькая загвоздка -исполнение кода при
этом самом detach отягощена некоторыми особенностями.
(Кстати, они могут быть не только внутри windows, но
и внутри дельфийского rtl). Так как оным завершателям
наши заботы ульрафиолетовы, а управлять оным
процессом, видимо, невозможно, нам остается лишь
время от времени лечиться у доктора Ватсона.

Ну, и , наконец, представим, что нашу библиотеку
решили (скажем, в угоду прогрессу) отдать сразу
нескольким потокам (да на нескольких процессорах).
А чего - вполне реально ;)

Делать выводы каждый сам.

Свое мнение я уже говорил.
Богу- богово, кесарю - кесарево.

-
Regards, LVT.

2 Leonid Troyanovsky © (29.06.06 19:35) [158]
Думаю, многие уже готовы посмотреть на иллюстрацию к сказанному в [158] о возможных проблемах.
Понимаю, у Вас найдутся дела и поинтереснее, но пока все стороны воздерживаются от примеров (которые можно "потрогать"), приходится верить (или нет) на слово.
У меня, к примеру, с момента [80] так и не появилось никакого мнения ни о сабже, ни об остальном в этой ветке.
Мне пока совершенно не очевидно изящество решения Пусика [150] (жду с нетерпением уточнений по экп-м ф-ям), как и реальность проблем из [158].

> Fay © (29.06.06 19:50) [159]

> Понимаю, у Вас найдутся дела и поинтереснее, но пока все
> стороны воздерживаются от примеров (которые можно "потрогать"),
> приходится верить (или нет) на слово.

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

Долго искал, мучился, эксперементировал с переменным успехом,
пока старшие товарищи не научили смотреть на вещи без розовых очков.

Эти принципы я усвоил, позволю их повторить:
1. использовать dll только тогда, когда без оной обойтись нельзя.
2. не использовать объекты в in, out & inside dll.

После & - это уже мои собс-ные выводы на базе определенного
эмпирического опыта воспроизведения трудноуловимых глюков.
Правда, примеры я не коллекционировал, бо, видимо, не
задумывался о их полезности в нынешней дискуссии.

Однако, неприятные ощущения от того опыта остались.
Они легко воспроизводятся при словах dll+OOP.

Кстати, я еще давно заметил, что сторонники dll+OOP обычно
напористы и агрессивны (маньякально-депрессивны -шут.)

Видимо, каждый из них проходит через "озарение" (И был очень рад..),
и искренне полагает, что все дельфийское сообщество прошло стороной.

Ну, а ларчик открывается просто.
MS не было нужды (= не было возможности) делать dll
объектно ориентированной.
Когда оные нужды созрели - появился и COM и .NET.
Какие уж тут, dll. Пора, IMHO, оставить старушку в покое :)

Извини, брат, за отсутствие кода,
театр закрывается, нас всех тошнит (с) Хармс.

--
Regards, LVT.

Экспорт / импорт (dll) функций из класса Найти похожие ветки