Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: < 1 2 3 4 5 6 7 8 9 10 >
parovoZZ © (2006-06-27 05:35:00)
К примеру, запись
exports TMyClass.myFunc name 'MyFunc';
ошибочна. А как быть?

BiN (2006-06-29 15:25:00) [61]

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

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

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

Игорь Шевченко (2006-06-29 15:23:00) [62]

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

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

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

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

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

Пусик (2006-06-29 15:19:00) [63]

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

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

Шпиён (2006-06-29 15:07:00) [64]

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

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

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

Игорь Шевченко (2006-06-29 15:07:00) [65]
Fay © (29.06.06 15:05) [121]

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

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

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

BiN (2006-06-29 15:00:00) [67]

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

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

Игорь Шевченко (2006-06-29 15:00:00) [68]
Пусик © (29.06.06 14:43) [114]

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

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

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

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

Fay © (29.06.06 14:52) [116]

> И чё? См. [76]

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

Шпиён (2006-06-29 14:59:00) [69]

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

Почему? %)))

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

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

Шпиён (2006-06-29 14:50:00) [72]

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

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

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

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

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

Пусик (2006-06-29 14:43:00) [73]

> 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:23:00) [74]
Fay © (29.06.06 14:17) [112]

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

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

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

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

Игорь Шевченко (2006-06-29 14:15:00) [77]

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

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

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

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

Пусик (2006-06-29 14:11:00) [78]

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

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

Пусик (2006-06-29 14:10:00) [79]

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

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

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

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

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

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

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

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

Игорь Шевченко (2006-06-29 14:04:00) [80]
Пусик © (29.06.06 13:48) [102]

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

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

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

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

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

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

Страницы: < 1 2 3 4 5 6 7 8 9 10 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »