Подключить библиотеку dll

Данным диалектом Бейсика не пользуясь, но иногда здесь бываю. Решил немного поучаствовать. Собственно вопрос в следующем: можно ли пользоватся сторонними библиотеками в этом диалекте, насколько сложен процесс использования? Цель - есть своя xll для VBA, можно убрать обертку будет dll, выложу здесь для тех кто много считает, большими числами) (Гугл не спрашивал ибо важно понять, есть целесообразность в данном продукте?)

0

А где у вас путь в декларации?

Сообщение от The trick Set cSum = CreateCOMObject()

, разве это не позднее связывание (динамическое), уже при выполнении программы?

0

Сообщение от The trick В качестве демонстрации платформо-независимости COM, сделал небольшой пример на C который не использует платформозависимые функции и возможности

Что-то все слишком усложнено. Достигнуть такого результата можно без IUnknown.
DLL.EXE.Если нужно чтобы одна функция Create() позволяла создавать несколько объектов, то проще и логичнее передавать его имя или идентификатор через аргумент функции т. е. Create("TestCOM") а не пользоваться для этого возможностями IUnknown идентифицируя через малопонятный GUID.

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

Вложения

TestCOM.zip (5.0 Кб, 1 просмотров)

0

Сообщение от bedvit , разве это не позднее связывание (динамическое), уже при выполнении программы?

Нет, это способ создания объекта.

Сообщение от locm Что-то все слишком усложнено. Достигнуть такого результата можно без IUnknown.

Нет.
Во-первых, где счетчик ссылок? Если объект передается куда-то там в другую процедуру, как основное приложение определит когда нужно очистить объект?
Во-вторых, как на этом примере реализуется концепция интерфейсов? К примеру один объект реализует несколько интерфейсов, как это будет выглядеть в этом коде?

Сообщение от locm Если нужно чтобы одна функция Create() позволяла создавать несколько объектов, то проще и логичнее передавать его имя или идентификатор через аргумент функции т. е. Create("TestCOM") а не пользоваться для этого возможностями IUnknown идентифицируя через малопонятный GUID.

А причем тут IUnknown для создания объекта? IUnknown служит для запроса интерфейса и управления жизнью COM объекта.

Сообщение от locm Если нужно чтобы одна функция Create() позволяла создавать несколько объектов, то проще и логичнее передавать его имя или идентификатор через аргумент функции

Так и делается. См. определение функции DllGetClassObject.

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

Ну во-первых, не зная параметры функций - как работать, это просто не имеет смысла. Во-вторых, раз уж так хочется, то есть OLE Automation и позднее связывание (как-то же это работает в vbs/vba/1С?). В-третьих, в примере не продемонстрировано множественное наследование интерфейсов, как в моем примере на C (интерфейсы ISum, IDiff). (Я бы тоже мог сделать пустышки для IUnknown и код был бы ну на 2 строчки больше твоего по функционалу это было бы одно и тоже). В-четвертых, для Windows мы имеем большое количество вспомогательных функций для работы с COM (загрузка в отдельный процесс, независимость от битности, синхронизация для STA, ....). В-пятых, с твоей DLL не будут работать языки VBA/VB6/VBS/JS/1С как минимум.

0

Сообщение от The trick Во-первых, где счетчик ссылок? Если объект передается куда-то там в другую процедуру, как основное приложение определит когда нужно очистить объект?

Зачем он нужен в данном случае? Вызов метода Release() уничтожит объект. В коде это видно.

Сообщение от The trick Во-вторых, как на этом примере реализуется концепция интерфейсов? К примеру один объект реализует несколько интерфейсов, как это будет выглядеть в этом коде?

Именно это подразумевал под

Сообщение от locm Если нужно чтобы одна функция Create() позволяла создавать несколько объектов, то проще и логичнее передавать его имя или идентификатор через аргумент функции т. е. Create("TestCOM") а не пользоваться для этого возможностями IUnknown идентифицируя через малопонятный GUID.

Сообщение от The trick Во-вторых, раз уж так хочется, то есть OLE Automation и позднее связывание (как-то же это работает в vbs/vba/1С?)

Сообщение от The trick См. определение функции DllGetClassObject.

А как же платформонезависимость? Работать с DllGetClassObject придется напрямую и думаю понимаете что получится гораздо сложнее чем экспорт функций из процедурной DLL.

Сообщение от The trick В-пятых, с твоей DLL не будут работать языки VBA/VB6/VBS/JS/1С как минимум.

Зато многие другие будут работать (их намного больше), которые позволяют экспортировать функции из DLL. Среди перечисленных это умеют как минимум VBA и VB6.

0

del

0

Сообщение от locm Зачем он нужен в данном случае? Вызов метода Release() уничтожит объект. В коде это видно.

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

Сообщение от locm Именно это подразумевал под

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

Сообщение от locm А как же платформонезависимость? Работать с DllGetClassObject придется напрямую и думаю понимаете что получится гораздо сложнее чем экспорт функций из процедурной DLL.

А причем тут кроссплатформенность? Ну вызывай эту функцию из Linux, в чем проблема? Не нравится, хорошо создай свою другую как у меня CreateCOMObject.

Сообщение от locm Зато многие другие будут работать (их намного больше), которые позволяют экспортировать функции из DLL. Среди перечисленных это умеют как минимум VBA и VB6.

Те, многие другие будут работать и с COM DLL. С COM мы получаем множество преимуществ, я уже приводил пример с плагинами. Не знаю как это реализовать без "костылей" через кучу экспортируемых функций.

0

Сообщение от The trick Как зачем? Ну мы реализуем DLL которая распоряжается объектом, а если она передает объект в другую DLL

Если объект используется зачем его уничтожать? Функция Create() создает, а вызов метода Release() уничтожает. Все просто и логично.

Сообщение от The trick я уже приводил пример с плагинами. Не знаю как это реализовать без "костылей" через кучу экспортируемых функций.

WinAPI хороший пример подобной реализации.

0

Сообщение от The trick , разве это не позднее связывание (динамическое), уже при выполнении программы? Нет, это способ создания объекта.

Да похоже так. Был невнимателен.

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

0

Сообщение от locm Если объект используется зачем его уничтожать? Функция Create() создает, а вызов метода Release() уничтожает. Все просто и логично.

Нет. Если бы все было так просто люди не городили смарт поинтеры и т.п. вещи. К примеру ты создаешь объект в процедуре и передаешь его в API, а она к примеру хранит этот объект. Когда ты должен его удалять? При выходе из процедуры? А если другая библиотека его использует? Будет креш? Счетчик решает эту проблему посредством инкриминирования. Ты вышел из зоны видимости и декриминировал счетчик, когда объект никому не нужен счетчик его обнуляется и он удаляется.

Сообщение от locm WinAPI хороший пример подобной реализации.

WinAPI - это плагины?

0

Сообщение от The trick К примеру ты создаешь объект в процедуре и передаешь его в API, а она к примеру хранит этот объект. Когда ты должен его удалять?

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

Сообщение от The trick WinAPI - это плагины?

Это пример как можно обойтись без объектов. Не исключено что WinAPI функции работают с объектами, к примеру hWnd может быть объектом (а может и не быть).

0

Сообщение от bedvit По-моему полезная дискуссия

А по мне, как со стороны видно, так это обычный холивар между профессионалом, который владеет всеми современными технологиями программирования и человеком, который застрял в процедурном программировании и не владеет знаниями о ООП, а от того не видит ни каких преимуществ.
Но главный вопрос топика таки остался нерешённым -

Сообщение от bedvit Собрал dll под разную разрядность:

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

0

Сообщение от locm Это должно быть документировано. Тогда вопросов не возникнет.

Ты не сможешь предусмотреть все варианты. В случае когда твою библиотеку использует другая библиотека которая в свою очередь используется приложением создающим объекты, имеющими свойства в виде других объектов это будет головная боль. К примеру какой-нибудь контейнер который хранит объекты разного типа. Для COM это просто вызов Release когда объект больше не используется и никаких проверок типов объектов (если их несколько) и отслеживания жизни объекта. Прекрасный аналогичный пример - умные указатели в C++.

Сообщение от locm Это пример как можно обойтись без объектов.

Причем здесь плагины? Перефразирую, в каком месте WinAPI реализована концепция плагинов? Все плагины в Windows реализованы через COM, к примеру расширения оболочки.

Сообщение от locm Не исключено что WinAPI функции работают с объектами, к примеру hWnd может быть объектом (а может и не быть).

Во-первых, существуют множество функций работающих с COM объектами в WinAPI. Во-вторых, насколько мне известно WINAPI разрабатывался еще на C и для C программистов еще очень давно, а MS заботится об обратной совместимости. Та же работа с DirectX (любая версия) основана на COM, работа со звуком, различные новые функции работы с диалоговыми окнами, работа с файлами, все основано на COM.
Второй момент это то что я не являюсь противником классического подхода, я спрашиваю чем COM хуже? Также показываю его преимущества перед классическим методом, что в некоторых случаях COM более удобен.

0

Сообщение от The trick Для COM это просто вызов Release когда объект больше не используется

А если забыть вызвать Release или вызвать несколько раз?

0

Сообщение от locm А если забыть вызвать Release или вызвать несколько раз?

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

0

Сообщение от The trick Забыв вызвать Release - получишь утечку памяти также как в твоем случае.

Т. е. в реальности преимуществ нет.

Сообщение от The trick В твоем случае непонятно когда вызывать Release.

Когда экземпляр объекта больше не нужен. По коду должно быть понятно. Create создает экземпляры объекта, а Release их удаляет. Считай что Create это конструктор, а Release деструктор.

0

Сообщение от locm Т. е. в реальности преимуществ нет.

Есть. В моем случае понятно когда вызывать Release.

Сообщение от locm Когда экземпляр объекта больше не нужен. По коду должно быть понятно. Create создает экземпляры объекта, а Release их удаляет. Считай что Create это конструктор, а Release деструктор.

Как ты можешь знать когда экземпляр больше не нужен? Это головная боль даже если ты просто в своем приложении используешь объекты, но если твои объекты используются не тобой - то это почти невозможно предугадать. Самый простой пример - это ресурсы Windows. К примеру тот-же hProcess, любое приложение может открыть кучу дескрипторов одного и того же процесса. В Windows ведется учет через счетчик ссылок. Когда все приложения закроют хендлы тогда объект удалится т.к. счетчик обнулится. Теперь просто перенесем эту концепцию на COM объекты, клиенты получают доступ к COM объекту, т.к. тут есть счетчик ссылок, то все понятно когда все клиенты "закроют хендлы" вызовут Release объект можно удалить. В твоем случае когда вызывать Release без счетчика ссылок?

0

Сообщение от The trick В моем случае понятно когда вызывать Release.

В моем тоже. Когда экземпляр объекта больше не нужен, следует вызвать Release.

Сообщение от The trick Как ты можешь знать когда экземпляр больше не нужен?

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

Сообщение от The trick К примеру тот-же hProcess, любое приложение может открыть кучу дескрипторов одного и того же процесса.

Это помешает завершить процесс? Что будет с этой кучей дескрипторов, есть процесс больше не существует?

Сообщение от The trick Это головная боль даже если ты просто в своем приложении используешь объекты, но если твои объекты используются не тобой - то это почти невозможно предугадать.

Сообщение от The trick клиенты получают доступ к COM объекту, т.к. тут есть счетчик ссылок, то все понятно когда все клиенты "закроют хендлы" вызовут Release объект можно удалить.

А если в коде ошибка из-за которой Release будет вызван большее или меньшее чем необходимо число раз (о чем я писал выше)? Так что метод с подсчетом ссылок не решает проблемы корректного использования объекта сторонним кодом.

0

Сообщение от Pro_grammer удалось ли подключить Вашу либу к этим простым языкам FB и PB? Насколько быстро это работает, и возможно собственные решения на FB или PB работают быстрее?

здесь обсуждение по этой теме:
iforum . pro / freebasic-93 / podklyuchit-biblioteku-dll-7772 / index6.html#post28961 (ссылку не пропускает, удалите пробелы)

Сообщение от Pro_grammer А по мне, как со стороны видно, так это обычный холивар между профессионалом, который владеет всеми современными технологиями программирования и человеком, который застрял в процедурном программировании и не владеет знаниями о ООП, а от того не видит ни каких преимуществ.

в том и интерес, считаю. Разные точки зрения дают больше информации.

0

Сообщение от locm В моем тоже. Когда экземпляр объекта больше не нужен, следует вызвать Release.

Кому не нужен? Как ты можешь знать кто использует твой объект извне? Ты говоришь о самом простом случае создал объект, попользовался - удалил. Я говорю о другом сценарии, создал объект и его ссылку скопировали себе 10 других Dll, когда вызывать Release?

Сообщение от locm Если я пишу программу то могу знать, также как знаю когда следует освободить память, запрошенную у системы, или закрыть ранее открытый файл, или любой другой ресурс запрошенный у системы через WinAPI.

Теперь мысленно перенеси себя не на пользователя ресурсов WinAPI, а на провайдера ресурсов и станет понятно.

Сообщение от locm Это помешает завершить процесс? Что будет с этой кучей дескрипторов, есть процесс больше не существует?

А причем тут завершение процесса? Это совершенно другой процесс. Ты что не разу не отслеживал завершение процесса или потока? Что происходит с хендлом тогда? Да ничего, объект ядра процесс не удалится пока не будут закрыты все дескрипторы. Ты все также можешь получить код завершения процесса и т.п.

Сообщение от locm А если в коде ошибка из-за которой Release будет вызван большее или меньшее чем необходимо число раз (о чем я писал выше)?

Ну ошибка - это ошибка. Мы говорим о корректном коде. В твоем случае все тоже самое.

Сообщение от locm Так что метод с подсчетом ссылок не решает проблемы корректного использования объекта сторонним кодом.

Так корректного использования или некорректного? При корректном использовании все будет работать нормально.

0

Сообщение от The trick Так корректного использования или некорректного? При корректном использовании все будет работать нормально.

При корректном использовании и мой метод нормально работает.

1