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

← →
parovoZZ © (2006-06-27 05:35) [0]

К примеру, запись
exports TMyClass.myFunc name "MyFunc";
ошибочна. А как быть?

← →
atruhin © (2006-06-27 06:17) [1]

Создать процедуры "обертки"
function CreateClass : TMyClass;
....
function myFunc(Class : TMyClass) : .....
begin
result := Class.myFunc;
end;
......
procedure DestroyClass(Class : TMyClass);
....

← →
Amoeba © (2006-06-27 12:07) [2]

Следует заметить, что одноименные классы в DLL и основной программе будут (если компилировались без пакетов) "разными", т.е. будут иметь не общую, а разные VMT.

← →
parovoZZ © (2006-06-27 16:35) [3]

> Создать процедуры "обертки"function CreateClass : TMyClass;
> ....function myFunc(Class : TMyClass) : .....begin result
> := Class.myFunc;end;......procedure DestroyClass(Class :
> TMyClass);

Хм, я так и думал. Тогда классы в dll мало чего дают.

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

> Хм, я так и думал. Тогда классы в dll мало чего дают.

Классы много чего дают в bpl

← →
Romkin © (2006-06-27 17:53) [5]

А еще больше дает ActiveX library :-Р

← →
Пусик © (2006-06-27 21:00) [6]

> parovoZZ © (27.06.06 16:35) [3]
> > Создать процедуры "обертки"function CreateClass : TMyClass;
> > ....function myFunc(Class : TMyClass) : .....begin result
> > := Class.myFunc;end;......procedure DestroyClass(Class
> :> TMyClass);Хм, я так и думал. Тогда классы в dll мало
> чего дают.

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

← →
Leonid Troyanovsky © (2006-06-27 21:40) [7]

> Пусик © (27.06.06 21:00) [6]

> Как и везде, классы дают именно то, для чего предназначены

Для работы в dll классы не предназначены.
Потому как dll есть совершенно особый вид PE, не ориентированный
на объектную модель. За исключением специальных случаев,
упомянутых ранее [4, 5].

--
Regards, LVT.

← →
Пусик © (2006-06-27 21:42) [8]

> Leonid Troyanovsky © (27.06.06 21:40) [7]
> > Пусик © (27.06.06 21:00) [6] > Как и везде, классы дают
> именно то, для чего предназначены Для работы в dll классы
> не предназначены.

Это нужно понимать так, что в DLL не рекомендуется использовать ООП?

← →
Leonid Troyanovsky © (2006-06-27 21:52) [9]

> Пусик © (27.06.06 21:42) [8]

> Это нужно понимать так, что в DLL не рекомендуется использовать
> ООП?

[4] - для дельфийского применения (однако, bpl "приивязаны" к exe).
[5] - универсально (ес-но, с недельфийской объектной моделью).

--
Regards, LVT.

← →
Шпиён (2006-06-27 23:51) [10]

> Leonid Troyanovsky © (27.06.06 21:40) [7]
>
>
> Для работы в dll классы не предназначены.

Ж%-О Не понял....

← →
Leonid Troyanovsky © (2006-06-27 23:59) [11]

> Шпиён (27.06.06 23:51) [10]

> > Для работы в dll классы не предназначены.

> Ж%-О Не понял....

Дык, не стесняйся, спрашивай.

--
Regards, LVT.

← →
Шпиён (2006-06-28 00:10) [12]

> Leonid Troyanovsky © (27.06.06 23:59) [11]

Так и спрашиваю.... что такого особенного в классах, что противопоказано для dll (если, конечно, не экспортировать их оттуда)???

← →
Leonid Troyanovsky © (2006-06-28 00:23) [13]

> Шпиён (28.06.06 00:10) [12]

> Так и спрашиваю.... что такого особенного в классах, что
> противопоказано для dll (если, конечно, не экспортировать
> их оттуда)???

А если их не экспортировать оттуда, т.е., если можно
обмениваться лишь простыми (необъектными) типами,
то, нет никакой нужды в использовании этих объектов.
Особенно - VCL, не рассчитанной на работу в dll.

--
Regards, LVT.

← →
Шпиён (2006-06-28 01:25) [14]

Ну не знаю. Если мне для решения задачи удобнее использовать классы - я все равно их использую, кошерно это или нет. А если обоснованно потребуется goto - использую goto...кто бы что об этом ни говорил.
ps А причем тут VCL? ООП, imho, все же нечто большее, чем VCL...

← →
Leonid Troyanovsky © (2006-06-28 06:49) [15]

> Шпиён (28.06.06 01:25) [14]

> Ну не знаю. Если мне для решения задачи удобнее использовать
> классы - я все равно их использую

Пример удобного использования объекта в dll в студию, плиз.

--
Regards, LVT.

← →
Leonid Troyanovsky © (2006-06-28 06:52) [16]

> Шпиён (28.06.06 01:25) [14]

> ps А причем тут VCL? ООП, imho, все же нечто большее, чем
> VCL...

"Особенно - VCL" = "для некоторой (особой) части ООП".

--
Regards, LVT.

← →
Пусик © (2006-06-28 09:33) [17]

> Leonid Troyanovsky © (28.06.06 06:49) [15]
> Пример удобного использования объекта в dll
> в студию, плиз.

Да примеров полно.

- Класс-наследник TStrings с дополнительными функциями поиска файлов, обработки(например, копирования).
- Специализированные классы-обертки Winsock.

Продолжать список бессмысленно, так спектр возможных задач настолько широк, насколько широки вообще потребности в ЛЮБЫХ программах.

Говорить о том, что ООП не предназначено для использования в DLL - то же самое, что говорить, будто бензин предназначен только для использования в мотоциклах.

← →
Fay © (2006-06-28 09:47) [18]

2 Пусик © (28.06.06 9:33) [17]
> Да примеров полно.

Не вижу ни одного примера. Только декларация их существования.

← →
Шпиён (2006-06-28 09:48) [19]

> Leonid Troyanovsky © (28.06.06 06:49) [15]
>
>
> Пример удобного использования объекта в dll в студию, плиз.
>

Пример:
Дано:
1) "Сторонний" (соседнего отдела) скриптовый интерпретатор с поддержкой плагинов-расширений (в виде подключаемых dll).
2) Готовые и отлаженные smpp-компоненты (другой разработчик).

Задача: Создать плагин для реализации "скриптового" smpp-клиента.

← →
Игорь Шевченко © (2006-06-28 09:48) [20]

> Говорить о том, что ООП не предназначено для использования
> в DLL - то же самое, что говорить, будто бензин предназначен
> только для использования в мотоциклах.

До тех пор, пока ООП присутствует внутри DLL и не вылезает наружу о каком-то использовании его говорить не стоит. Мало ли, что там у DLL внутри.

← →
Пусик © (2006-06-28 10:22) [21]

> Игорь Шевченко © (28.06.06 09:48) [20]
>До тех пор, пока
> ООП присутствует внутри DLL и не вылезает наружу о каком-
> то использовании его говорить не стоит.

Так все же, используется ООП внутри DLL или не используется?

Если его нельзя/не рекомендуется использовать, то почему?
Если же ООП в DLL используется, то почему нельзя говорить об этом? Это секретная информация?

← →
Пусик © (2006-06-28 10:22) [22]

> Fay © (28.06.06 09:47) [18]
> 2 Пусик © (28.06.06 9:33) [17]> Да примеров полно.Не вижу
> ни одного примера. Только декларация их существования.

Практическую реализацию я оставлю на твое усмотрение.

← →
Пусик © (2006-06-28 10:23) [23]

Удалено модератором
Примечание: Offtopic

← →
Fay © (2006-06-28 10:30) [24]

Удалено модератором
Примечание: Offtopic

← →
Игорь Шевченко © (2006-06-28 10:31) [25]

Пусик © (28.06.06 10:22) [21]

Дело в том, что DLL не является чем-то самостоятельным. С точки зрения программы, использующей DLL, DLL представляет только набор процедур, которые надо вызывать, поэтому как реализованы внутренности DLL, программе неинтересно. Вот в C++, например, можно в DLL объявить базовые классы и в основной программе наследоваться от них, здесь уже можно говорить про ООП с использованием DLL. Тоже самое с пакетами в Delphi.

← →
Fay © (2006-06-28 10:35) [26]

2 Leonid Troyanovsky © (27.06.06 21:52) [9]
> однако, bpl "приивязаны" к exe
В смысле?

← →
Игорь Шевченко © (2006-06-28 10:37) [27]

Fay © (28.06.06 10:35) [26]

> В смысле?

В смысле, что ниоткуда, кроме как из EXE той же версии Delphi, их использовать не получится.

← →
Fay © (2006-06-28 10:41) [28]

2 Игорь Шевченко © (28.06.06 10:37) [27]
Ах в этом смысле... 8) Наверное так и нужно было сказать.
Я, конечно, не допускаю мысли, что Leonid Troyanovsky думал то же, что написал, но не уточнить не мог 8)

← →
Пусик © (2006-06-28 10:56) [29]

> Игорь Шевченко © (28.06.06 10:31) [25]
> Пусик © (28.06.06 10:22) [21] Дело в том, что DLL не является
> чем-то самостоятельным.

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

Я думаю, что LVT весьма неосторожновысказал фразу о том, что ООП не предназначено для использования в DLL.
Методы ООП прекрасно помогают писать код как в обычной программе, так и в DLL.
И мне непонятно, к каким негативным последствиям может привести сложный код, реализованный с использование ООП в DLL.
Именно о отрицательных сторонах использования ООП в DLL и хотелось бы услышать в подтверждение своих слов от Леонида Трояновского.

← →
Adder © (2006-06-28 11:04) [30]

> Игорь Шевченко © (28.06.06 10:31) [25]

Хм... однако

"ООП с использованием DLL" и "Использование в DLL"

абсолютно разные вещи (imho).

← →
Игорь Шевченко © (2006-06-28 11:11) [31]

Пусик © (28.06.06 10:56) [29]

> Но DLL, однако, является самодостаточной.
> И имеет ценность сама по себе, а не только в составе какой-
> либо отдельной программы.

Это как ? Объясни пожалуйста. DLL ведь нельзя запустить на выполнение.

> Методы ООП прекрасно помогают писать код как в обычной программе,
> так и в DLL.

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

← →
Игорь Шевченко © (2006-06-28 11:14) [32]

Adder © (28.06.06 11:04) [30]

А тему ветки поглядеть не судьба ?

← →
Adder © (2006-06-28 11:21) [33]

> Игорь Шевченко © (28.06.06 11:14) [32]

А причем тут тема ветки... Тему ветки забудут, а фразу запомнят..
И еще и повторять будут с умным видом в самых не подходящих для этого случаях.

← →
Пусик © (2006-06-28 11:22) [34]

> Это как ? Объясни пожалуйста. DLL ведь нельзя запустить
> на выполнение.

Можно. Например, использовать RunDll32.exe для выполнения некоторой функции из DLL.

> DLL с классами внутре может быть смело заменена на DLL без
> классов внутре,

Зачем? Для чего отказываться от ООП в DLL? Какие есть для этого причины?

← →
Игорь Шевченко © (2006-06-28 11:24) [35]

Adder © (28.06.06 11:21) [33]

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

← →
Игорь Шевченко © (2006-06-28 11:30) [36]

Пусик © (28.06.06 11:22) [34]

> для выполнения некоторой функции из DLL

Ты сказал! (с) Евангелие

Именно функции, а не метода какого-либо объекта.

> Зачем? Для чего отказываться от ООП в DLL? Какие есть для
> этого причины?

Например, написав DLL на языке, не имеющем средств ООП. И тем не менее, такая DLL будет исправно выполнять свой контракт, описанный в ейном интерфейсе. Я к тому, что реализация DLL с использованием ООП или без использования его не влияет на внешние по отношению к DLL программы.

"Мало ли, что там у DLL внутри" (с)

← →
Пусик © (2006-06-28 11:35) [37]

Удалено модератором

← →
ЕГыук (2006-06-28 16:44) [38]

> DLL ведь нельзя запустить на выполнение.

rundll

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

ЕГыук (28.06.06 16:44) [38]

[36]

← →
Leonid Troyanovsky © (2006-06-28 19:31) [40]

> Пусик © (28.06.06 10:56) [29]

> И имеет ценность сама по себе, а не только в составе какой-
> либо отдельной программы.

Dll не имеет никакой самостоятельной ценности, т.е. вне хоста.
Просто, это такая примитивная форма модели клиент-сервер.

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

Я пока не видел аргументов за использование ООП в dll.
(Впрочем, как, собс-но, и обоснований необходимости использования dll).

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

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

> Я думаю, что LVT весьма неосторожновысказал фразу о том,
> что ООП не предназначено для использования в DLL.

Конечно, не предназначены. Какая уж тут осторожность.
Максимум ООП, что можно выжать из dll есть COM (см. [5])

> и хотелось бы услышать в подтверждение своих слов от Леонида
> Трояновского.

Извольте-с.
Не используйте объекты в длл и будет вам счастье.
И, вообще, не используйте длл, если без оной можно обойтись.

--
Regards, LVT.

← →
Leonid Troyanovsky © (2006-06-28 19:34) [41]

> Fay © (28.06.06 10:41) [28]

> Ах в этом смысле... 8) Наверное так и нужно было сказать.

Да, хотелось сказать, что они повязаны версией дельфи,
но с утра бывает сложно формулировать мысль.
Хотя, конечно, иногда и вечером тож :)

--
Regards, LVT.

← →
Leonid Troyanovsky © (2006-06-28 19:40) [42]

> Пусик © (28.06.06 09:33) [17]

> - Класс-наследник TStrings с дополнительными функциями поиска
> файлов, обработки(например, копирования).
> - Специализированные классы-обертки Winsock.

Ой-ой-ой. Т.е., без классов мы уже не можем реализовать
ни работу со строками. ни поиск файлов?

И чего там особо специализированного в оных обертках winsock?
Хочется немного объектов? Изволь. Только нечего их
тащить еще в одну длл. Будьте любезны ложить в exe.

--
Regards, LVT.

← →
Leonid Troyanovsky © (2006-06-28 19:45) [43]

> Пусик © (28.06.06 09:33) [17]

> Продолжать список бессмысленно, так спектр возможных задач
> настолько широк, насколько широки вообще потребности в ЛЮБЫХ
> программах.

Дык, вот, если немного поразмышлять о предназначении ООП
и тех же dll, то можно придти к простому выводу, что для
столь неограниченного круга задач нужны именно простые
(а не объектные) типы данных.
Т.е., на входе, на выходе и в нутре.

--
Regards, LVT.

← →
Leonid Troyanovsky © (2006-06-28 19:49) [44]

> Adder © (28.06.06 11:04) [30]

> абсолютно разные вещи (imho).

Что сова о пень, что пнем о сову,
все равно, не жить сове.

Если уж на фундаменте exe еще можно построить объектный
мир из необъектных кирпичей, то не стоит это делать в dll,
бо, уж сильно она не самостоятельна.

--
Regards, LVT.

← →
Leonid Troyanovsky © (2006-06-28 20:00) [45]

> Пусик © (28.06.06 11:22) [34]

> Можно. Например, использовать RunDll32.exe для выполнения
> некоторой функции из DLL.

Оная предназначена лишь для вызова функций вполне
определенного прототипа.
Да, собс-но, это не так уж и важно.

--
Regards, LVT.

← →
Leonid Troyanovsky © (2006-06-28 20:06) [46]

> Шпиён (28.06.06 09:48) [19]

> 1) "Сторонний" (соседнего отдела) скриптовый интерпретатор
> с поддержкой плагинов-расширений (в виде подключаемых dll).
>
> 2) Готовые и отлаженные smpp-компоненты (другой разработчик).
>
> Задача: Создать плагин для реализации "скриптового" smpp-
> клиента.

Чего-то больно много натяжек (нет, чтоб по-простому, на кастрюльках).
Так и хочется послать куда-нибудь в vbs.
И, чтоб другой разработчик подтянулся.

--
Regards, LVT.

← →
Fay © (2006-06-28 20:12) [47]

Леонид разбушевался 8)

← →
Пусик © (2006-06-28 20:28) [48]

Цитата:
Leonid Troyanovsky © (27.06.06 21:40) [7]

Для работы в dll классы не предназначены.

Вопрос такой: почему для работы в DLL классы не предназначены?
Какие есть причины не использовать классы в DLL?

← →
Пусик © (2006-06-28 20:34) [49]

> Leonid Troyanovsky © (28.06.06 19:31) [40]

> Я пока не видел аргументов за использование ООП в dll.

А я пока не видела против.

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

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

Можно свести все к простым типам. Тогда для чего создано ООП? Для облегчения разработки, однако.
И почему же я должна отказаться от ООП? Вследствие того, что тебе не нравится использование ООП в DLL?

> Извольте-с.Не используйте объекты в длл и будет вам счастье.

У меня счастье и отсуствие проблем и с DLL вместе. Чего и тебе желаю.

> И, вообще, не используйте длл, если без оной можно обойтись.

Почти единственное высказывание, с которым можно согласиться.

← →
Пусик © (2006-06-28 20:37) [50]

> Leonid Troyanovsky © (28.06.06 20:00) [45]
> > Пусик © (28.06.06 11:22) [34] > Можно. Например, использовать
> RunDll32.exe для выполнения > некоторой функции из DLL.Оная
> предназначена лишь для вызова функций вполне определенного
> прототипа.Да, собс-но, это не так уж и важно.

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

← →
Fay © (2006-06-28 20:41) [51]

2 Пусик © (28.06.06 20:37) [50]
Не осилил 3-е предложение...
М.б. перефразируешь?

← →
Пусик © (2006-06-28 20:43) [52]

Все же хотелось бы услышать на ясно и четко поставленный вопрос в постах [12],[29],[34],[48] такой же четкий и ясный ответ.

Аргументы навроде "Нет нужды использовать" - аргументами, естественно, не являются. Это то же самое, что нет нужды использовать стиральную машину - ведь можно руками постирать.

← →
Пусик © (2006-06-28 20:44) [53]

> Fay © (28.06.06 20:41) [51]
> 2 Пусик © (28.06.06 20:37) [50]Не осилил 3-е предложение.
> ..

Идущий осилит.

← →
Шпиён (2006-06-28 20:44) [54]

> Leonid Troyanovsky © (28.06.06 20:06) [46]

> Чего-то больно много натяжек (нет, чтоб по-простому, на
> кастрюльках).

Ни одной натяжки. Абсолютно реальная ситуация.
Задача была очень быстро создать smpp-клиент для функционального и нагрузочного тестирования sms-центра. Причем клиент именно "скриптовый", позволяющий максимально просто (так, чтобы с этим мог справиться не программист) описывать выполнять различные сценарии работы, в том числе и некорректные. Плюс - возможность трассировки (дампы пакетов).
Скриптовый интерпретатор и все его вывихи - следовало принимать как данность (наш плагин - не единственный, плагины можно подключать по несколько штук, цепочкой, добавляя нужные команды), компоненты - тоже. Времени на собственную реализацию протокола SMPP - ноль целых, шиш десятых (и нецелесообразно при наличии готовой и отлаженной реализации).
Клиент создан и работает.

← →
Leonid Troyanovsky © (2006-06-28 20:48) [55]

> Fay © (28.06.06 20:12) [47]

Отлучился на службу, а тут вовсю отцвели стереотипы :)
Не сдержался, sorry.

--
Regards, LVT.

← →
Leonid Troyanovsky © (2006-06-28 20:58) [56]

> Пусик © (28.06.06 20:28) [48]

> Вопрос такой: почему для работы в DLL классы не предназначены?
> Какие есть причины не использовать классы в DLL?

Как я понял, достаточно ответить лишь на один из них?
OK. Отвечаю.

Классическая dll ориентирована на работу лишь с простыми
(необъектными) типами.
Поэтому, создание, изменение и разрушение объектов
есть лишние расходы в оной модели.

Возможен вопрос, а почему же в exe возможно
построение объектного мира, скажем дельфийского?
Отвечаю: exe, т.е. породитель процесса играет именно
ту самую роль "самодостаточности" в рамках win32,
которые некотрые упорно (необоснованно) приписывают dll.

--
Regards, LVT.

← →
Пусик © (2006-06-28 21:09) [57]

> Классическая dll ориентирована на работу лишь с простыми
> (необъектными) типами.Поэтому, создание, изменение и разрушение
> объектовесть лишние расходы в оной модели.

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

← →
Leonid Troyanovsky © (2006-06-28 21:12) [58]

> Пусик © (28.06.06 20:34) [49]

> И почему же я должна отказаться от ООП? Вследствие того,
> что тебе не нравится использование ООП в DLL?

У меня не было цели отвратить Пусика от оных деяний.
Т.е., каждый - сам себе злобный Буратино.

Что не нравится? Можно перечитать, IMHO, я не в многих
постах столь многословен.

> У меня счастье и отсуствие проблем и с DLL вместе. Чего
> и тебе желаю.

Спасибо.
Но, дело ж не только в нас?

> Почти единственное высказывание, с которым можно согласиться.

Огласите весь список, пжлст.

--
Regards, LVT.

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

> В-третьих, какие могут быть дополнительные расходы при использовании
> классов?
> Выделение памяти? Какая разница, выделяется память для простого
> типа или для объекта?

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

← →
Leonid Troyanovsky © (2006-06-28 21:16) [60]

> Пусик © (28.06.06 20:37) [50]

> Совершенно верно. Не важно. Важен факт, что DLL может иметь
> вполне самостоятельное значение для вызова функций вполне
> определенного
> прототипа

Странное понимение самостоятельности.
Т.е., мало что в рамках процесса, предоставляемого rundll,
но, и в рамках _определенного_ протокола.

--
Regards, LVT.

← →
Leonid Troyanovsky © (2006-06-28 21:17) [61]

> Leonid Troyanovsky © (28.06.06 21:16) [60]

> но, и в рамках _определенного_ протокола.

Прототипа, тьфу.
Sorry.

--
Regards, LVT.

← →
Пусик © (2006-06-28 21:22) [62]

> Leonid Troyanovsky © (28.06.06 21:12) [58]
>Но, дело ж не
> только в нас?

А в ком?
Есть мы - те, кто дискутирует, а есть факты из жизни Windows.
Факты - они для всех едины.

> Огласите весь список, пжлст.

Зачем? Дискуссия по поводу "использовать или не использовать ООП в DLL" имеет мало отношения к начальной теме.
Имеет ли смысл вытаскивать все те высказывания, с которыми я согласна и не согласна, отфильтровывать их по категориям?

> Т.е., каждый - сам себе злобный Буратино.

Опять же - дело не взлобности к самому себе, а в поисках истины.

Убедительных доводов против моего мнения я не увидела пока.
То, что надо осторожно работать в DLL - и так понятно, думаю, что тут комментарии и не требуются.

Ну вот не вижу я минусов. НЕ ВИЖУ.

← →
Leonid Troyanovsky © (2006-06-28 21:24) [63]

> Шпиён (28.06.06 20:44) [54]

> Ни одной натяжки. Абсолютно реальная ситуация.

Реальность, IMHO, и есть причина большинства натяжек.
Назовем это здоровым компромиссом.
Т.е., никому не хотелось трахаться с чужим кодом и
все потекли по течению.

Однако, это вовсе не основание для того, чтобы включать
изваяенного франкейштейна в "плагин" (видимо, dll, sorry).

--
Regards, LVT.

← →
Пусик © (2006-06-28 21:34) [64]

Ладно. Надо завязывать. Все равно агументов, похоже, хороших нет.
Пусть каждый остается при своем мнении.

← →
Шпиён (2006-06-28 21:37) [65]

> Leonid Troyanovsky © (28.06.06 21:24) [63]

Считаешь, нужно было СОМ прикрутить? Так накладные расходы почище, чем на создание объекта в dll будут.
А "трахаться" с чужим кодом в 270К, когда на все - неделя - мазохистов нет, это и называется - неудобство.
Хорошая программа - та, которая работает 1)правильно 2)надежно 3)ресурсов потребляет не больше, чем допустимо . Имхо, единственный критерий.
А что там у нее внутри - это внутреннее дело программиста.
Но лучше уж объекты, чем "лапша", если дальнейшая поддержка предполагается.

← →
Leonid Troyanovsky © (2006-06-28 21:38) [66]

> Пусик © (28.06.06 21:22) [62]

> Факты - они для всех едины.

Ну, и в чем есть сермяжная правда жизни Windows?

> я согласна и не согласна, отфильтровывать их по категориям?

Конечно, лучше уж по категориям, чем огульно.
Бо, тезисов я, IMHO, предоставил вполне.

> Убедительных доводов против моего мнения я не увидела пока.

Ну, а я не увидел к-л обоснований оного мнения.
За исключением, наверное, частных, т.е. " у меня все ок".

> То, что надо осторожно работать в DLL - и так понятно, думаю,
> что тут комментарии и не требуются.

А кто говорил про осторожно?
Я, например, говорил не таясь: работать с длл не надо.

> Ну вот не вижу я минусов. НЕ ВИЖУ.

Не стоит этим гордится, IMHO.
У некотрых, пардон, дальтонизм g(gправда, у женщин редкость),
у некоторых близорукость, дальнозоркость или астигматизм.

--
Regards, LVT.

← →
Leonid Troyanovsky © (2006-06-28 21:46) [67]

> Шпиён (28.06.06 21:37) [65]

> Считаешь, нужно было СОМ прикрутить? Так накладные расходы
> почище, чем на создание объекта в dll будут.

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

--
Regards, LVT.

← →
Пусик © (2006-06-28 21:54) [68]

> Я, например, говорил не таясь: работать с длл не надо.

Вообще-то, это абсолютно голословное утверждение.

Сортировка и фильтрация(цветом помечены высказывания, с которыми не согласна):

А если их не экспортировать оттуда, т.е., если можно обмениваться лишь простыми (необъектными) типами, то, нет никакой нужды в использовании этих объектов.
Особенно - VCL, не рассчитанной на работу в dll.

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

Конечно, не предназначены. Какая уж тут осторожность. Максимум ООП, что можно выжать из dll есть COM (см. [5])

Не используйте объекты в длл и будет вам счастье. И, вообще, не используйте длл, если без оной можно обойтись.

И чего там особо специализированного в оных обертках winsock? Хочется немного объектов? Изволь. Только нечего их тащить еще в одну длл. Будьте любезны ложить в exe.

Если уж на фундаменте exe еще можно построить объектный мир из необъектных кирпичей, то не стоит это делать в dll, бо, уж сильно она не самостоятельна.

И, вообще, не используйте длл, если без оной можно обойтись.

--------------

Ну, и в чем есть сермяжная правда жизни Windows?

В том, что Indows(как и DLL) существует независимо от того, что мы думаем о них.

Ну, а я не увидел к-л обоснований оного мнения.

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

> Не стоит этим гордится, IMHO.У некотрых, пардон, дальтонизм
> g(gправда, у женщин редкость),у некоторых близорукость,
> дальнозоркость или астигматизм.

Совершенно верно. А у некоторых закостенелые консервативные убеждения. Я бы сказала, на уровне ретроградства.
Чем гордиться не стоит.

А вот гордиться тем, что у меня все хорошо - стоит.

← →
Пусик © (2006-06-28 21:56) [69]

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

А что, если будешь использовать ООП, то неделфийцы не смогут вкусить плодов?

← →
Пусик © (2006-06-28 21:58) [70]

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

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

← →
Leonid Troyanovsky © (2006-06-28 22:15) [71]

> Пусик © (28.06.06 21:54) [68]

> > Я, например, говорил не таясь: работать с длл не надо.

> Вообще-то, это абсолютно голословное утверждение.

Никто ж не просил оснований (опровержений).
Однако, такое я заявлял.

> Сортировка и фильтрация(цветом помечены высказывания, с
> которыми не согласна):

Допустим. Однако, мне не понятно, что же из нижеследующего
вызвало не согласие:

> 1. Создать объект
> 2. Заполнить его поля некоторыми простых типами,
> переданными из хоста.
> 3. Сделать некоторые пассы.
> 4. Вернуть хосту нужные простые типы из полей.
> 5. Разрушить объект.

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

Да, и, собс-но

> Максимум ООП, что можно выжать из dll есть COM (см. [5])

> И чего там особо специализированного в оных обертках winsock?

> Хочется немного объектов? Изволь. Только нечего их
> тащить еще в одну длл. Будьте любезны ложить в exe.

> Если уж на фундаменте exe еще можно построить объектный
> мир из необъектных кирпичей, то не стоит это делать в dll,
> бо, уж сильно она не самостоятельна.

Хорошо бы к-л контраргументов.
А то, все равно, огульно. Я ж тоже могу собрать чьи-то
посты, подчеркнуть жирно и сказать: не согласен.

> Ну, и в чем есть сермяжная правда жизни Windows?

> В том, что Indows(как и DLL) существует независимо от того,
> что мы думаем о них.

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

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

Ограничения, IMHO, изложены вполне доступно:
то, что лежит вне преобразования простых типов данных
в dll есть overheads, или чрезмерно приумножаемые сущности.

> А вот гордиться тем, что у меня все хорошо - стоит.

Как у волка на морозе? :)

Я ж уже говорил, тезисов я выдвинул предостаточно.
Только, плиз, без огульности.

--
Regards, LVT.

← →
Игорь Шевченко © (2006-06-28 22:17) [72]

Шпиён (28.06.06 21:16) [59]

> Другое дело, что они компенсируются упрощением повторного
> использования и поддержки кода.

Это в DLL или в где ? :)

← →
Leonid Troyanovsky © (2006-06-28 22:17) [73]

> Пусик © (28.06.06 21:56) [69]

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

> А что, если будешь использовать ООП, то неделфийцы не смогут
> вкусить плодов?

Пардон, а как они будут вкушать, если им будут доступны
лишь простые типы данных и регулярные процедуры.

--
Regards, LVT.

← →
Игорь Шевченко © (2006-06-28 22:20) [74]

Пусик © (28.06.06 21:54) [68]

> В том, что Indows(как и DLL) существует независимо от того,
> что мы думаем о них.

Ага, существуют. И Волга впадает в Каспийское море. Только в Windows объектов нету :) А тут вроде речь об ООП.

← →
Игорь Шевченко © (2006-06-28 22:26) [75]

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

Можно услышать. Классы в Delphi из DLL не экспортируются. А насчет демагогии - в зеркало, плз

← →
Fay © (2006-06-28 22:28) [76]

2 Игорь Шевченко © (28.06.06 22:26) [75]
> Классы в Delphi из DLL не экспортируются.
Игорь, речь уже давно идёт об использовании классов внутри реализации экспортируемых функций. 8)

← →
Leonid Troyanovsky © (2006-06-28 22:29) [77]

> Пусик © (28.06.06 21:58) [70]

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

Девствительно. Я, понимаешь, излагаю целую теорию [40],
а в ответ слышу "предложения без конкретной аргументации".

Изволь высказать свой путь ООП внутре dll.
Ну, и, дальше, мы будем следовать со всеми остановками.

--
Regards, LVT.

← →
Leonid Troyanovsky © (2006-06-28 22:34) [78]

> Fay © (28.06.06 22:28) [76]

> Игорь, речь уже давно идёт об использовании классов внутри
> реализации экспортируемых функций. 8)

Не.
Борьба, на самом деле, идет за каждый байт пресловутой dll.

Может ты сомневаешься в целесообразности неиспользования
объектов в длл?
Или в неиспользовании самих длл? :)

--
Regards, LVT.

← →
Игорь Шевченко © (2006-06-28 22:44) [79]

Fay © (28.06.06 22:28) [76]

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

Так в каком из постов уже было сказано, что внутри экспортирумеых функций можно хоть черта лысого использовать - от этого никому ни горячо ни холодно. Даже при передаче объектов в качестве параметров код для невиртуальных методов дублируется. А с виртуальными можно на грабли понаступать из-за дублирования таблиц VMT в DLL и в EXE.

← →
Fay © (2006-06-28 22:45) [80]

2 Leonid Troyanovsky © (28.06.06 22:34) [78]
> Борьба, на самом деле, идет за каждый байт пресловутой dll.
Чё, серьёзно? А мне пофиг...
> Может ты сомневаешься в целесообразности неиспользования объектов в длл?
Сами библиотеки мне редко бывают нужны, а классы в них и вовсе не встречаются. Правда, я не избавлялся от них специально - просто необходимость не возникала. Т.о. у меня нет чёткой позиции по этому вопросу (наш офтопик), нет проверенной в боях доктрины 8)

Сомневаюсь ли я в целесообразности неиспользования длл? Не знаю, не думал (и не буду) об этом, пойду лучше - жену поцелую 8).

← →
Fay © (2006-06-28 22:46) [81]

2 Игорь Шевченко © (28.06.06 22:44) [79]
А интерфейсы передавать кошерно?

← →
Джо © (2006-06-28 22:51) [82]

> [81] Fay © (28.06.06 22:46)
> 2 Игорь Шевченко © (28.06.06 22:44) [79]
> А интерфейсы передавать кошерно?

Интерфейсы, как ни крути — это часть концепции самой ОС. :) Ну, то есть, COM-интерфейсы.

← →
Leonid Troyanovsky © (2006-06-28 22:54) [83]

> Fay © (28.06.06 22:45) [80]

> Сомневаюсь ли я в целесообразности неиспользования длл?
> Не знаю, не думал (и не буду) об этом, пойду лучше - жену
> поцелую 8).

Понимаю, бо это серьезно.

Однако, это также вселяет уверенность, что dll без нужды
использоваться не будет ;)

--
Regards, LVT.

← →
Игорь Шевченко © (2006-06-28 23:04) [84]

Fay © (28.06.06 22:46) [81]

> А интерфейсы передавать кошерно?

Я сильно похож на раввина ? :)

← →
Шпиён (2006-06-28 23:17) [85]

> Leonid Troyanovsky © (28.06.06 22:54) [83]

> Однако, это также вселяет уверенность, что dll без нужды
> использоваться не будет ;)

Я не Fay, но тоже отвечу -)

Без нужды я не только Dll и ООП не буду использовать...без нужды я вообще ни строчки кода не напишу :Р
Ну, разве что для собственного развлечения...но это тоже нужда своего рода -)))

← →
Пусик © (2006-06-29 00:14) [86]

> Да, и, собс-но> Максимум ООП, что можно выжать из dll есть
> COM (см. [5])> И чего там особо специализированного в оных
> обертках winsock?> Хочется немного объектов? Изволь. Только
> нечего их> тащить еще в одну длл. Будьте любезны ложить
> в exe.> Если уж на фундаменте exe еще можно построить объектный>
> мир из необъектных кирпичей, то не стоит это делать в dll,
> > бо, уж сильно она не самостоятельна.Хорошо бы к-л контраргументов.
> А то, все равно, огульно. Я ж тоже могу собрать чьи-топосты,
> подчеркнуть жирно и сказать: не согласен.

Аргумент - пожалуйста.

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

Для примера: Нужно мне реализовать список с функциональностью TList.
Исходя из твоих принципов, ты подобный список будешь реализовывать с нуля. Зачем? Время, затраченное на разработку такого списка, я лучше потрачу на другие вещи.
В чем я не права? Чем мне грозит использование ООП (в данном случае класса TList) в DLL?

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

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

> Ограничения, IMHO, изложены вполне доступно:то, что лежит
> вне преобразования простых типов данныхв dll есть overheads,
> или чрезмерно приумножаемые сущности.

Откуда взялись такие ограничения? Я не встречала таких. Поэтому не вижу в них реальных аргументов.

> > А вот гордиться тем, что у меня все хорошо - стоит.Как
> у волка на морозе? :)

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

> Я ж уже говорил, тезисов я выдвинул предостаточно.Только,
> плиз, без огульности.

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

← →
Leonid Troyanovsky © (2006-06-29 00:39) [87]

> Пусик © (29.06.06 00:14) [86]

> Для примера: Нужно мне реализовать список с функциональностью
> TList.

Пардон, с какой функциональностью?
А не кажется ли уважаемому Пусику, что необходимую функциональность
некоторые индивидуумы реализую быстрее, чем некотроые найдут искомый
класс в исходниках VCL

> Исходя из твоих принципов, ты подобный список будешь реализовывать
> с нуля. Зачем? Время, затраченное на разработку такого списка,

Если моя карма не смогла бы меня уберечь от столь гнусного занятия,
то, я бы, все равно, потратил доступное мне время на реализацию
лишь требуемой функциональности (отнюдь, не класса в dll).

> В чем я не права? Чем мне грозит использование ООП (в данном
> случае класса TList) в DLL?

Хороший вопрос.
Но, тут возникает другой: чукча - писатель, или он еще и читатель?

> Откуда взялись такие ограничения? Я не встречала таких.
> Поэтому не вижу в них реальных аргументов.

[40]

> Я могу гордиться тем, что у меныя, в отличие от господина
> Трояновского, не возникает проблем с использованием ООП
> в DLL.

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

> Все сказанные тезисы расписаны в предыдущих абзацах и не
> выдерживают самой простой критики.

Самую простую критику формулировать ведь не сложно?

--
Regards, LVT.

← →
Шпиён (2006-06-29 00:54) [88]

> Leonid Troyanovsky © (29.06.06 00:39) [87]

> [40]

[79] -)

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

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

Не кажется. Давай посоревнуемся? Я создам экземпляр класса TList, а ты реализуешь его в полном объеме без использования ООП?

Думаю, не надо говорить, кто поставленную задачу выполнит быстрее?

> Если моя карма не смогла бы меня уберечь от столь гнусного
> занятия,то, я бы, все равно, потратил доступное мне время
> на реализацию лишь требуемой функциональности (отнюдь, не
> класса в dll).

Некоторые работают, некоторые - велосипед изобретают.
Каждому свое.

> Хороший вопрос.Но, тут возникает другой: чукча - писатель,
> или он еще и читатель?

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

> > Откуда взялись такие ограничения? Я не встречала таких.
> > Поэтому не вижу в них реальных аргументов.[40]

В посте №40 единственная настораживающая фраза - "увеличение сущностей".
Думаю, что если посчитать количество кода, которое придется написать, "Сущностей" появится значительно больше. По-моему, даже и сравнивать не стоит.

Так что и эта фраза - мимо кассы.

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

А пробовал ли? Я уже что-то сильно сомневаться начала в этом.

> Самую простую критику формулировать ведь не сложно?

А критика заключается в следующем:

Все вышеозначенные аргументы являются не чем иным, как высосанными из пальца общими словами, не подтвержденными АБСОЛЮТНО ничем.

Я бы сказала, что с самого начала обсуждения все твои высказывания являются ни чем иным, как попытками оправдать свою ошибку и нежеланием признать это.

Верный тезис таков:

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

← →
Leonid Troyanovsky © (2006-06-29 01:13) [90]

> Шпиён (29.06.06 00:54) [88]

> [79] -)

Я, по своей скромной возможности, попытался даже
усилить оный тезис.

--
Regards, LVT.

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

На этой ноте позвольте распрощаться.

← →
Leonid Troyanovsky © (2006-06-29 01:43) [92]

> Пусик © (29.06.06 01:12) [89]

> Не кажется. Давай посоревнуемся? Я создам экземпляр класса
> TList, а ты реализуешь его в полном объеме без использования
> ООП?

Странно, что-то не было вопросов насчет in-out параметров.
Ну, а реализовывать в полном объеме я и не собирался ;)
бо overheads и нафик не нужно.

Ладно, читаем дальше.

> Некоторые работают, некоторые - велосипед изобретают.

Skip.

> > или он еще и читатель?

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

И в чем оскорбления? У меня вполне обоснованные сомнения
в работоспособности read, если 40 пост, видимо, не прочитан
после 87.

> Думаю, что если посчитать количество кода, которое придется
> написать, "Сущностей" появится значительно больше. По-моему,
> даже и сравнивать не стоит.

Их надо посчитать, бо речь не об экзешнике, а о длл.

> А пробовал ли? Я уже что-то сильно сомневаться начала в
> этом.

Пробывал чего? Не использовать длл?
Увы, не всегда возможно.
Но, уж если без этого никак, то без объектов - легко :)

> являются ни чем иным, как попытками оправдать свою ошибку

Пардон, какую ошибку?

> Верный тезис таков:

> ООП нужно использовать там, где это удобно, в том числе
> и в DLL.

Предположим, что так.

> Ограничениями являются естественные системные ограничения
> и общие требования, предъявляемые к загружаемым библиотекам.

Соглашусь.
Оно, кстати, херит всю пусиковскую теорию.

--
Regards, LVT.

← →
Пусик © (2006-06-29 13:01) [93]

> Leonid Troyanovsky © (28.06.06 22:29) [77]
>
> > Пусик © (28.06.06 21:58) [70]
>
> > Честно говоря, уже надоело выслушивать предложения без
> конкретной
> > аргументации.
>
>
> Девствительно. Я, понимаешь, излагаю целую теорию [40],
> а в ответ слышу "предложения без конкретной аргументации".
>

Мда. Специально перечитала пост № [40].

Не ожидала, что человек со значком мастера будет нести такой бред.

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

Пусик © (29.06.06 13:01) [93]

> Не ожидала, что человек со значком мастера будет нести такой
> бред.

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

← →
Пусик © (2006-06-29 13:25) [95]

> А ты матчасть почитай,

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

← →
Пусик © (2006-06-29 13:26) [96]

А без этого - пустой безосновательный треп.

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

> А ты ссылку дай - на тему с ограничениями использования
> ООП в DLL

Это всегда пожалуйста: http://delphimaster.net/view/1-1151372156/

← →
Пусик © (2006-06-29 13:30) [98]

> Игорь Шевченко © (29.06.06 13:26) [97]
>
> > А ты ссылку дай - на тему с ограничениями использования
>
> > ООП в DLL
>
>
> Это всегда пожалуйста: http://www.delphimaster.ru/cgi-bin/forum.
> pl?n=0&id=1151372156

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

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

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

Пусик © (29.06.06 13:30) [98]

Сдается мне, что участники дискуссии не ставят своей целью убедить лично тебя, а приводят аргументы, исходя из здравого смысла. Можно ездить из Копена в Гаген через Крыжополь, никто не запрещает, безусловно.
Кстати, насколько я вижу, ты не приводишь аргументов за полезность использования объектов при реализации функций в DLL, кроме аргумента "мне так удобнее". Удобнее - ради Аллаха, никто из участников дискуссии не покушается на твое удобство. Просто дискуссию не только ты читаешь, вдруг кто задумается и выводы сделает...

← →
Пусик © (2006-06-29 13:39) [100]

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

Здравого смысла пока не было в высказываниях.

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

Тебе нужны аргументы за высказывание "На Delphi можно программировать?"

Нет? Тогда почему ты от меня аргументов требуешь?
Вот если бы я сказала "На Delphi нельзя сдклать то-то и то-то", вот тогда ты мог бы потребовать предоставить аргументы.

> Просто дискуссию не только ты читаешь, вдруг кто задумается
> и выводы сделает...

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

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

Пусик © (29.06.06 13:39) [100]

> Здравого смысла пока не было в высказываниях.

Например, в посте № 40.

> Тебе нужны аргументы за высказывание "На Delphi можно программировать?
> "

Аргументы за высказывание "Волга впадает в Каспийское море" мне тоже не нужны.

> Тогда почему ты от меня аргументов требуешь?

Типа дискуссия. Аргументы "мне удобнее" и "все, кто несогласен, несут бред" извини, хороши для дошкольного возраста.

> Наслушавшись баек от некоторых товарищей, некоторые могу
> решить, что они говорят правду

Приведи хотя бы обоснованные аргументы, почему они говорят неправду. Ключевое слово "обоснованные"

← →
Пусик © (2006-06-29 13:48) [102]

> Типа дискуссия. Аргументы "мне удобнее" и "все, кто несогласен,
> несут бред" извини, хороши для дошкольного возраста.

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

Бред - он и есть бред. Сказки рассказывайте детям на ночь. А здесь взрослые люди общаются и все высказывания без аргументов можно интерпретировать не иначе, как бред.

> Приведи хотя бы обоснованные аргументы, почему они говорят
> неправду. Ключевое слово "обоснованные"

Потому что использование ООП в DLL не приводит ни к каким проблемам.
Достаточно? нет? Ах, нет?? Тогда опровергни меня?

Ну где же аргументы? Не вижу.

← →
Пусик © (2006-06-29 13:49) [103]

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

← →
Fay © (2006-06-29 13:53) [104]

2 Пусик © (29.06.06 13:49) [103]
Ты, видимо, пропустила самое главное - Леонид (с его слов) борется за каждый байт ([78]). Не могу сказать, что разделяю подобное благородное устремление, но это объясняет все его (Леонида) аргументы.

← →
Пусик © (2006-06-29 13:57) [105]

> Fay © (29.06.06 13:53) [104]
> 2 Пусик © (29.06.06 13:49) [103]
> Ты, видимо, пропустила самое главное - Леонид (с его слов)
> борется за каждый байт ([78]). Не могу сказать, что разделяю
> подобное благородное устремление, но это объясняет все его
> (Леонида) аргументы.

Ну тогда ему следовало бы указать, что это он борется, и поэтому не использует, вместо того, чтобы утверждать вышеуказанную точку зрения, что это его личная точка зрения, и нне более того.

← →
Fay © (2006-06-29 14:02) [106]

2 Пусик © (29.06.06 13:57) [105]
> Ну тогда ему следовало бы указать, что это он борется, и поэтому не использует,
Он совершенно недвусмысленно сказал об этом.
> что это его личная точка зрения, и нне более того.
Леонид ни разу на дал понять, что выражает чужую точку зрения.

З.Ы.
Наверное тему поря замять... Это просто ещё одна разновидность священной войны.

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

Пусик © (29.06.06 13:48) [102]

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

Не все взрослые.

> Потому что использование ООП в DLL не приводит ни к каким
> проблемам.

Безусловно, в большинстве случаев не приводит. Из Копена в Гаген через Крыжополь тоже можно ездить. И лишнюю работу можно делать. Только зачем ?

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

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

← →
Пусик © (2006-06-29 14:10) [108]

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

Не будем говорить о преимуществах. Преимущества ООП - отдельная тема.
Вопрос о невозможности использования ООП в DLL.
Уже 10 раз было сказано, что можно, так как никаких запретов и от MS нет.

Хватит разводить демагогию!
Если нет аргументов, так и скажи. Пока я не видела ссылки или цитаты от MS о таких ограничениях.

> Безусловно, в большинстве случаев не приводит. Из Копена
> в Гаген через Крыжополь тоже можно ездить. И лишнюю работу
> можно делать. Только зачем ?

Лишняя работа - это ограничивать себя в средствах разработки.

В Крыжополь можешь ездить как угодно. К теме дискуссии туристические поездки никакого отношения не имеют.

> Безусловно, в большинстве случаев не приводит.

Ну и? В каких же приводят?

← →
Пусик © (2006-06-29 14:11) [109]

> Fay © (29.06.06 14:02) [106]
> 2 Пусик © (29.06.06 13:57) [105]
> > Ну тогда ему следовало бы указать, что это он борется,
> и поэтому не использует,
> Он совершенно недвусмысленно сказал об этом.

Сошлись на его постинг, пожалуйста.

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

> Вопрос о невозможности использования ООП в DLL.

А где было утверждение о невозможности ?

> Ну и? В каких же приводят?

В классическом "Cannot assign TFont to TFont"

← →
Fay © (2006-06-29 14:15) [111]

2 Пусик © (29.06.06 14:11) [109]
> Сошлись на его постинг, пожалуйста.
Повторяю - [78]

← →
Fay © (2006-06-29 14:17) [112]

2 Игорь Шевченко © (29.06.06 14:15) [110]
> В классическом "Cannot assign TFont to TFont"
А можно поподробнее? Для меня и всех в моём танке...

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

Fay © (29.06.06 14:17) [112]

> А можно поподробнее? Для меня и всех в моём танке...

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

← →
Пусик © (2006-06-29 14:43) [114]

> Fay © (29.06.06 14:15) [111]
> 2 Пусик © (29.06.06 14:11) [109]
> > Сошлись на его постинг, пожалуйста.
> Повторяю - [78]

Нет, ты ссылку дай на его высказывание, где LVT говорит, что это его личное мнение.

> Игорь Шевченко © (29.06.06 14:15) [110]
>
> > Вопрос о невозможности использования ООП в DLL.
>
>
>
> > Ну и? В каких же приводят?
>
>
> В классическом "Cannot assign TFont to TFont"

А разве ООП=VCL?

об этом еще вв начале топика сказано было. Не надо по второму кругу начинать.

> А где было утверждение о невозможности ?

Ну, если угодно, высказывание "Нельзя", или если дословно,

> Для работы в dll классы не предназначены.

На логичный вопрос "Почему?" ответа нет до сих пор.

Кстати, пара цитат:
Почитай свои высказывания. За ними следует вопрос.

Игорь Шевченко © (28.06.06 09:48) [20]

> Говорить о том, что ООП не предназначено для использования
> в DLL - то же самое, что говорить, будто бензин предназначен
> только для использования в мотоциклах.

До тех пор, пока ООП присутствует внутри DLL и не вылезает наружу о каком-то использовании его говорить не стоит. Мало ли, что там у DLL внутри.

> Игорь Шевченко © (28.06.06 10:31) [25]
> Пусик © (28.06.06 10:22) [21]

> С точки зрения программы, использующей DLL, DLL представляет
> только набор процедур, которые надо вызывать, поэтому как
> реализованы внутренности DLL, программе неинтересно.

> Игорь Шевченко © (28.06.06 11:11) [31]
> Пусик © (28.06.06 10:56) [29]
>
> Я могу еще раз сказать, что программе безразлично, каким
> образом написан код в DLL, лишь бы процедурный интерфейс
> DLL выполнял свои функции. DLL с классами внутре может быть
> смело заменена на DLL без классов внутре, с точки зрения
> контракта между основной программой и DLL ничего не изменится.
>

Игорь Шевченко © (28.06.06 11:30) [36]
> Зачем? Для чего отказываться от ООП в DLL? Какие есть для
> этого причины?

Например, написав DLL на языке, не имеющем средств ООП. И тем не менее, такая DLL будет исправно выполнять свой контракт, описанный в ейном интерфейсе. Я к тому, что реализация DLL с использованием ООП или без использования его не влияет на внешние по отношению к DLL программы.

> Игорь Шевченко © (28.06.06 22:44) [79]
> Fay © (28.06.06 22:28) [76]
>
> Так в каком из постов уже было сказано, что внутри экспортирумеых
> функций можно хоть черта лысого использовать - от этого
> никому ни горячо ни холодно. Даже при передаче объектов
> в качестве параметров код для невиртуальных методов дублируется.> А с виртуальными можно на грабли понаступать из-за дублирования
> таблиц VMT в DLL и в EXE.

Так я не понял, ты выступаешь оппонентом Трояновскому? Или все же поддерживаешь его?

← →
Шпиён (2006-06-29 14:50) [115]

> Пусик © (29.06.06 14:10) [108]

> Вопрос о невозможности использования ООП в DLL.

Тут уже ты передергиваешь.

Утверждается, что использование объектов в dll нецелесообразно
Я даже согласен с этим - не стоит создавать класс ради самого класса и лепить dll только для того, "чтобы было". Если без этого можно легко обойтись - лучше обойтись. Гланды удалять через анус не стоит.
Но!
Приведенный мной частный случай целесообразности (когда, с одной стороны, по условию задачи (ТЗ, например) требуется именно dll и, с другой стороны, есть готовый объектный код, реализующий требуемую сложную функциональность) обозван "натяжкой" и аргументом не признан.

IMHO, налицо HolyWar, стороны остаются при своём мнении -)
Дальнейшая дискуссия может привети только к взаимным наездам.

← →
Fay © (2006-06-29 14:52) [116]

2 Игорь Шевченко © (29.06.06 14:23) [113]
> Поэтому классы в DLL ничего не знают о классах в приложении и наоборот.
И чё? См. [76]

← →
Fay © (2006-06-29 14:54) [117]

2 Шпиён (29.06.06 14:50) [115]
> Дальнейшая дискуссия может привети только к взаимным наездам.
Уже не может 8)

← →
Шпиён (2006-06-29 14:59) [118]

> Fay © (29.06.06 14:54) [117]

Почему? %)))

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

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

> Так я не понял, ты выступаешь оппонентом Трояновскому? Или
> все же поддерживаешь его?

Поддерживаю. С точки зрения поста [40]

> А разве ООП=VCL?
>
> об этом еще вв начале топика сказано было. Не надо по второму
> кругу начинать.

А что, таблицы VMT и операции AS и IS применимы только к VCL ? Я всю жизнь полагал, что они относятся ко всем классам.

Fay © (29.06.06 14:52) [116]

> И чё? См. [76]

И ниче. Если в качестве параметров функций передаются объекты из основного приложения, то есть шанс наступить на грабли [110]

← →
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]

Жму руку! :)

> Шпиён (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]

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

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

BiN © (29.06.06 15:54) [131]

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

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

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

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

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

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

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

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

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

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

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

BiN © (29.06.06 16:12) [137]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пусик © (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, как уже решенный в этой теме, выскажусь по поводу использования классов внутри реализации функций DLL.
Во-первых, ИМХО, спорящие забыли упомянуть исключениях, представленных в Дельфи классом Exception. Даже при процедурном программировании их применение часто позволяет сильно упростить код, избавив его, например, от множества ветвлений при последовательности сложных проверок и т.п.
Во-вторых, позволю напомнить о такой "разновидности" DLL, как CPL. Дельфи предлагает реализовывать эти DLL на основе класса TAppletModule и, собственно, VCL. Вы предпочитаете писать CPL на WinAPI ? Я нет - мне дороже мое время.
В-третьих вся реализация COM-серверов в DLL в Delphi от начала и до конца строится на ООП. (хотя про СОМ разговор особый - это конечно же не классические DLL)

Теперь немного о приведенных выше аргументах против:

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

Пока речь идет о классе типа TList - это да, это аргумент. Но вот есть у меня класс, ответственный за распознавание текста - его реализация занимает огромное число строчек кода и буде он мне понадобится в DLL мне и в голову не придет потратить несколько дней на выколупование отдельных процедур из этого класса - все равно, время, потраченное программой на создание/удаление экземпляра этого класса ничтожно по сравнением с исполнением задачи процедурой. Оптимизация должна быть разумной - разве я неправ ?

> без мучительных раздумий, как уследить за распределенной
> в длл памяти,

Разве в промежутке от 1 до 6 исполнение может быть прервано извне без завершения вызвавшего функцию потока ? А раз нет, то и никаких раздумий у нормального программиста не должно возникать.

> что будет, если будет повторный вызов в промежутке
> между 1 - 6 и т.д."

Собственно, ничего не будет, если поток создается и разрушается при каждом вызове.

Позволю себе немного обобщить - использование ООП внутри DLL, ИМХО, не привнесет никакого криминала, кроме некоторых накладных расходов связанных с соданием и разрушением объектов, которые имеет смысл учитывать лишь тогда, когда они соизмеримы со временем выполнения процедуры.

p.s. При создании DLL в Delphi через пункт New.., Delphi включает в нее модули SysUtils и Classes тем самым обуславливая создание как минимум 8 объектов ;)) Не будем считать программистов Borland"a такими уж дураками, не знающими , что "исполнение кода при этом самом detach отягощена некоторыми особенностями" ;)))

> Almaz © (29.06.06 20:39) [161]

> Borland"a такими уж дураками, не знающими , что "исполнение
> кода при этом самом detach отягощена некоторыми особенностями"
> ;)))

Конечно, не дураки, но всего лишь люди.
Из той же BDE (царствие ей небесное)
уж никак не получилась классическая dll.
И иной раз приходилось таки перегружаться,
из-за некорректной ее финализации.

--
Regards, LVT.

> Конечно, не дураки, но всего лишь люди.
> Из той же BDE (царствие ей небесное)
> уж никак не получилась классическая dll.

Аминь ;))

> И иной раз приходилось таки перегружаться,
> из-за некорректной ее финализации.

Там проблем хватало и без финализации ;)

Ну что же.
Пример я таки сделала.
Весьма схематично, но код рабочий.

Основной модуль:

unit ufMain; interface uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls; type TForm4 = class(TForm) Button1: TButton; procedure FormClose(Sender: TObject; var Action: TCloseAction); procedure FormCreate(Sender: TObject); procedure Button1Click(Sender: TObject); end; TProcessFile=function(FilePath: DWORD): BOOL; stdcall; var Form4: TForm4; HandleArray: array of THandle; ProcArray: array of TProcessFile; implementation {$R *.dfm} procedure GetFiles(const aPath: String;var aListFile: TStringList); var SR: TSearchRec; tPath: String; begin {$WARN SYMBOL_PLATFORM OFF} tPath := IncludeTrailingBackSlash(aPath); if FindFirst(tPath+"\*.*",faAnyFile,SR)=0 then begin try repeat if (SR.Name=".") or (SR.Name="..") then Continue; if (SR.Attr and faDirectory)<>0 then Continue else aListFile.Add(tPath+SR.Name); until FindNext(SR)<>0; finally Sysutils.FindClose(SR); end; end; {$WARN SYMBOL_PLATFORM ON} end; procedure TForm4.Button1Click(Sender: TObject); var L: TStringList; Ext: String; i: Integer; begin L := TStringList.Create; try GetFiles("c:\temp",L); for i := 0 to L.Count - 1 do begin Ext := AnsiUpperCase(ExtractFileExt(L[i])); if Ext=".TXT" then ProcArray[0](DWORD(PChar(L[i]))); if Ext=".DBF" then ProcArray[1](DWORD(PChar(L[i]))); end; finally L.Free; end; end; procedure TForm4.FormClose(Sender: TObject; var Action: TCloseAction); begin FreeLibrary(HandleArray[0]); FreeLibrary(HandleArray[1]); end; procedure TForm4.FormCreate(Sender: TObject); var H: THandle; Proc: TProcessFile; begin SetLength(HandleArray,2); SetLength(ProcArray,2); H := LoadLibrary("Dll1\FType1.dll"); HandleArray[0] := H; @Proc := GetProcAddress(H,"Process"); ProcArray[0] := @Proc; H := LoadLibrary("Dll2\FType2.dll"); HandleArray[1] := H; @Proc := GetProcAddress(H,"Process"); ProcArray[1] := @Proc; end; end.

Реализация родительского класса:

unit uParentCLass; interface uses classes; type TMainDLLClass=class public FFIlePath: String; FL: TStringList; constructor Create(const FilePath: String); destructor Destroy; override; function ProcessFile: Boolean; virtual; end; implementation { TMainDLLClass } constructor TMainDLLClass.Create(const FilePath: String); begin FFIlePath := FilePath; FL := TStringList.Create; end; destructor TMainDLLClass.Destroy; begin FL.Free; inherited; end; function TMainDLLClass.ProcessFile: Boolean; var i: Integer; begin Result := False; try FL.LoadFromFile(FFIlePath); for i := FL.Count - 1 downto 0 do begin if FL[i]="" then FL.Delete(i); end; FL.SaveToFile(FFIlePath); Result := True; except end; end; end.

DLL1:

library FType1; uses windows, SysUtils, Classes, uParentClass in "..\uParentClass.pas"; type TMainDLLClassType1=class(TMainDLLClass) public constructor Create(const FilePath: String); function ProcessFile: Boolean; override; end; { TMainDLLClassType1 } constructor TMainDLLClassType1.Create(const FilePath: String); begin inherited Create(FilePath); end; function TMainDLLClassType1.ProcessFile: Boolean; begin inherited ProcessFile; Result := True; //Здесь обработка файла нужного типа. end; function Process(FilePath: DWORD): BOOL; stdcall; var Obj: TMainDLLClassType1; begin Result := False; try Obj := TMainDLLClassType1.Create(PChar(FilePath)); try Result := Obj.ProcessFile; finally Obj.Free; end; except end; end; exports Process; end.

DLL2:

library FType2;
uses
windows,
SysUtils,
Classes,
uParentClass in "..\uParentClass.pas";

type

TMainDLLClassType2=class(TMainDLLClass)
public
constructor Create(const FilePath: String);
function ProcessFile: Boolean; override;

end;

{ TMainDLLClassType2 }

constructor TMainDLLClassType2.Create(const FilePath: String);
begin
inherited Create(FilePath);
end;

function TMainDLLClassType2.ProcessFile: Boolean;
begin
Result := True;
//Здесь обработка файла нужного типа.
end;

function Process(FilePath: DWORD): BOOL; stdcall; export;
var
Obj: TMainDLLClassType2;
begin
Result := False;
try
Obj := TMainDLLClassType2.Create(PChar(FilePath));
try
Result := Obj.ProcessFile;
finally
Obj.Free;
end;
except
end;
end;

exports
Process;
end.

Прошу прощения, отступы(табуляция) обрезались и в последнем посте код не выделила.

2 Пусик
Приведённый пример слишком хорошо подходит для иллюстрации сказанного в [40]. Это развод?

З.Ы.
> TProcessFile=function(FilePath: DWORD): BOOL; stdcall;
Если не секрет, почему именно DWORD ?

> Если не секрет, почему именно DWORD ?

Чтобы не возникло воросов об использовании DLL с хост-программами на другом языке программирования. DWORD - native type

> Приведённый пример слишком хорошо подходит для иллюстрации
> сказанного в [40].

Что тебя сподвигло на такое суждение?

2 Пусик
> Чтобы не возникло воросов
А указатель-то чем не угодил?

> Что тебя сподвигло на такое суждение?
Не вижу ваще никакого смысла в создании классов TMainDLLClass-идов - всё равно всё свелось к нескольким версиям одной процедуры.

> всё равно всё свелось к нескольким версиям одной процедуры.

А шире глянуть? Это всего лишь пример, иллюстрирующий применение ООП в DLL. Реализация реальных классов будет намного сложнее.

> А указатель-то чем не угодил?

А какая разница для иллюстрации?

Сорри. Две DLL. Но непринципиально это.

>Alx2 © (29.06.06 22:15) [174]

Итого - три независимых DLL.
Наследование в каждой начинается заново. Смысл?

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

> [176] Пусик © (29.06.06 22:25)

Я понимаю. Но смысла таки нет.
Если у нас A - предок B, C - его потомки, то в программе (классика) имеет место иерархия A, B(A), C(A).
У тебя, если покдючить обе DLL, получится
в первой: A1, B1(A1);
во второй: A2, B2(A2).
Причем A1<>A2
То есть имеем две совершенно чуждые друг другу ветви наследования.
Функционально A1=A2, но с точки зрения архитектуры A1<>A2. Смысл дублировать?
Вот примерно это я имел в виду.

Удалено модератором

> Игорь Шевченко © (30.06.06 10:56) [179]
> Пусик © (29.06.06 18:59) [156]
>
> Уважаемое, примите лекарство от хамства, совет такой добрый.
>

Ваши советы приберегите для LVT и прочая. Совет такой добрый.

Пусик © (30.06.06 11:23) [180]

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

Так... Добрались до сути. Собственно, разговор давно идёт в таком ключе, но форма изложения уже явно изменилась...

Пусик © (29.06.06 21:25) [166] [167] Здесь я вижу первый способ, который я приводил в [129]. Ничего нового :)
Для реализации используется ООП. <родительский класс-протокол>-MainDLL--> <Дочерний класс-протокол1>-Prot1DLL <Дочерний класс-протокол2>-Prot2DLL ... <Дочерний класс-протоколN>-ProtNDLL Периодически список обрабатываемых протоколов изменяется - одни устаревают и удаляются, новые появляются.

А интересен-то именно способ общения с объектами. Почему интересен? Очень просто: ну есть у нас система плагинов для подключения считывающих устройств. Вроде штрих-считывателей, картридеров и тд.Компонент + dll с определенным классом. Только я четко могу сказать, каким образом сделано: ActiveX. Соответственно, компонент регистрируется в категории, потом подгружается нужный, конфигурируется и идет работа.
Но это, как я уже говорил, не ООП :) Нет класса - общего предка плагина.

> Romkin © (30.06.06 12:41) [184]
> Fay © (30.06.06 11:38) [182] Скучно :) Воинствующий дилетантизм,
> как всегда.

Значит, использование ООП только этим исчерпывается?
Скажи, ты используешь обработку исключений в DLL?

Удалено модератором
Примечание: На [6] недопонятый, на [7] недопонявший. На чем и закончим.

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