Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

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

COM. Раннее связывание и ID-связывание. Есть ли реальное отличие?


Страницы:   1 2 3 4

Aleksey Pavlov ©   (2002-09-19 12:21:00) 

Приветствую Мастаков.
На днях, в связи с прочтением одной заметки, возник такой вопрос: какое отличие между ID и ранним связыванием (применительно к технологии COM)?
Я, вообще говоря, всегда думал, что раннее связывание и ID-связывание - это синонимы, т.к. при раннем связывании идентификаторы имён (ID of names) разрешаются на стадии компиляции и заносятся в VTable. Затем через интерфейс VTable осуществляется значительно более быстрый доступ к серверу автоматизации, чем через DispInterface, т.к. нам нет необхрдимости выполнять ф-ию GetIdOfNames интерфейса IDispatch.

В связи с этим, было высказанно мнение, что ID-связывание - это что-то промежуточное между ранним и поздним видом связывания, и что при использовании ID-связывании из Delphi необходимо применять DispInterface, т.к. в данном случае вызов производится через методы IDispatch.

Прошу прояснить ситуацию.
Заранее благодарен.


Aleksey Pavlov   (2002-09-23 13:25:00) [1]

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


Digitman   (2002-09-20 17:58:00) [2]

Соглоасен. Давайте на этом и остановимся пока, господа !


vuk   (2002-09-20 17:50:00) [3]

to Набережных С.
Поддерживаю! :o)


Набережных С.   (2002-09-20 17:47:00) [4]

Господа, ИМХО это вопрос чисто терминологический. Я когда-то для себя принял так:
> раннее связывание - это когда у компилятора есть информация о методах интерфейса
> позднее - соответственно наоборот
> особый случай - диспинтерфейсы
И меня такое деление вполне устраивает:)
А при чтении или разговоре из контекста всегда можно понять, о чем идет речь.


Romkin   (2002-09-20 17:36:00) [5]

2Digitman не совсем о маршаллинге, при реализации собственной заглушки через IMarshal механизм совершенно другой, это дает представление об RPC (вызов СОМ-сервера на удаленном компьютере)
А реализация маршалинга Борланд - частный случай, его можно делать и совершенно по-другому, например, можно (на Delphi!) написать собственный маршалинг потомков IUnknown, построив коклассы-заглушки, и передачу вызовов сделать любым образом, как захочешь


vuk   (2002-09-20 17:25:00) [6]

>При чем здесь tlb? исполнимого кода-то в ней нет.
Я ж говорю - можно пропустить. Я думал Вы о реализации Invoke...
Там можно очень удобно использовать tlb...


Digitman   (2002-09-20 17:13:00) [7]

>Romkin

100%-но согласен ! Именно SConnect дает наглядное представление о маршаллинге ! И спасибо-таки за это Борланду)... механизмы Proxy и Stub - там как на ладони)


vuk   (2002-09-20 17:12:00) [8]

>>Попробуйте "ручками" составить запрос на чистом С++ к методу
>>IDispatch::Invoke.
>А на кой? Можно ведь той же tlb пользоваться.
Извиняюсь, не так Вас понял. Можно это пропустить...


Romkin   (2002-09-20 17:12:00) [9]

Я имел в виду старые версии Васика, там этого не было
При чем здесь tlb? исполнимого кода-то в ней нет. Все дело в том, что Delphi усиленно скрывает детали работы интерфейсов, а на C++ они видны полностью (при желании), если не использовать макросы ATL
А на Delphi - comobj.DispatchInvoke


vuk   (2002-09-20 16:51:00) [10]

to Romkin:

>а VB понятия не имеет о структуре VTBL
Текущие версии VB, насколько мне известно, при наличии tlb используют VTable вызовы.

>Попробуйте "ручками" составить запрос на чистом С++ к методу
>IDispatch::Invoke.
А на кой? Можно ведь той же tlb пользоваться.


Romkin   (2002-09-20 16:48:00) [11]

Именно так... Только звено с rpc необязательно, я, например, часто работаю через Borland Socket Server, кстати, если кому интересно, SConnect.pas - там очень хорошо виден маршалинг :-))


vuk   (2002-09-20 16:44:00) [12]

>Разница-то какая с т.з. эффективности?
Как сказать. Вы уверены, что при вызове через Invoke не происходит следующее:
1. параметры упаковываются клиентом в формат Invoke
2. Делается вызов Invoke
3. Все это упаковывается в формат RPC
4. Делается вызов RPC
далее на стороне сервера:
5. Распаковывается из формата RPC
6. Параметры преобразуются в формат COM
7. Делается вызов соответствующего IDispatch.Invoke
8. Там параметры разбираются и вызывается соответствующий метод.

У меня почему-то подозрение, что все именно так и происходит. Если это так, то разница будет в количестве требуемых преобразований данных при вызове.


Romkin   (2002-09-20 16:43:00) [13]

Ж-)) ДА что тут искать? позднее связывание, как и IDispatch, было введено MS для того, чтобы программисты на VB могли делать вызовы к COM (а VB понятия не имеет о структуре VTBL). Ухи-то торчат! Достаточно посмотреть на параметры Invoke... В каком еще языке можно делать вызов метода типа Open(FileName = "aaa.doc", FileType = ...) да еще и с нетипированными параметрами?
В результате такое удобство на VB (VBA) превратилось в кошмар для программистов на C++ :-)) Попробуйте "ручками" составить запрос на чистом С++ к методу IDispatch::Invoke. Хорошо, ATL есть.
Вот и получилось - раннее связывание, когда имеется возможность доступа к таблице методов, и позднее, когда этого нет
А вот если сам написал маршалинг - все будет гораздо быстрее, исключая случай RPC


Digitman   (2002-09-20 16:30:00) [14]

>vuk

Это - да. Но - по определению MS. Не вдающегося в подробности. А на деле получается, что тот же в принципе Invoke() (но - в RPC) при разных условиях взаимодействия К. и С. всегда выглядит как методология ранее связывания, хотя IDispatch.Invoke() почему-то всегда ассоциируется с поздним. Разница-то какая с т.з. эффективности ? Да никакой на деле получается ! И там и там (тем или иным образом) фигурирует ID метода, разрешаемый в факт.адрес при исполнении Invoke().... Выигрыш в производительности за счет непосредственного обращения К. к заглушке сводится на нет тем или иным механизмом маршаллинга, без которого в принципе никак не обойтись...


vuk   (2002-09-20 16:11:00) [15]

Ведь что получается, если позднее связывание в COM Automation - это все что ходит через IDispatch.Invoke, то вызов VTable интерфейса через границу процессов не будет являться поздним связыванием.


Digitman   (2002-09-20 16:03:00) [16]

>Набережных С.

Я ведь тоже просто изложил свое понимание вещей) ...

>vuk

Не стоит звынений !) ... Мы ведь просто ищем истину) ... А истина здесь весьма расплывчата ...


vuk   (2002-09-20 15:58:00) [17]

Звиняйте, дяденьки... В случае позднего связывания в COM решение о том, какой именно метод вызывать и как параметры подставлять принимает сервер автоматизации (пара GetIDsOfNames/Invoke)... Здесь же что-то другое получается...


Набережных С.   (2002-09-20 15:47:00) [18]


> Digitman © (20.09.02 15:28)

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


Digitman   (2002-09-20 15:44:00) [19]

>vuk

Как бы там ни было, мы тут все же - о раннем и позднем связывании.
Вот и RPC тоже ведет к Invoke(). Пусть и не относящемуся к классическим дисаинтерфейсам.

И что ? Это - раннее связывание ? Или таки - позднее ?))


vuk   (2002-09-20 15:37:00) [20]

>а RPC ,по-твоему, не имеет никакого отношения к маршаллингу ?
Я что, утверждал обратное? Конечно имеет. Только вот это маршалинг не COM, а RPC. А единственное, с чем я спорю - это Ваши утверждения о том, что через пределы процесса не возможен VTbl вызов и тем, что маршалинг завязан на механизмы диспинтерфейсов.


Страницы:   1 2 3 4

Наверх

Титульная страница Поиск, карта сайта Написать письмо