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

Просто вставил в конец модуля "Сообщить" и оно вызывается при каждом вызове сервера.

В общем, ощущение что всю систему проектировал какой-то криворукий гоблин.

Короче, как я и сказал в (50) объекта "Обработка" просто вообще нет. Когда мы выполняем РеквизитФормыВЗначение("Объект") у нас создаётся объект "Обработка" по тем данным, которые были сохранены в форме (а там живут его реквизиты).
Можно считать, что вызывается конструктор с параметрами.
Теперь мы можем работать с нашим объектом.
Потом, когда мы закончиили работу, мы его должны сохранить в реквизит, чтобы данные реквизитов ему соответствовали.
То есть выполняем ЗначениеВРеквизитФормы.

В следующий раз, когда мы снова создаём объект, он создаётся в том состоянии, в котором мы его сохранили в реквизит.

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

(63) Если часть кластера упала, то клиенты должны переходить на другую часть, собственно именно тогда и переходить, а не каждый раз.

(66) А что делать с данными клиента, которые "держал" этот кусок кластера?

(64) Это не атавизм, это целая идеология программирования.
И от них никуда не денешься, так как эта реализация обеспечивает передачу данных между исполнителями независимо от среды. А по сути, это всего-лишь некоторая удобная надстройка над механизмом удалённого исполнения.

И потом, сами интерфейсы COM-объектов это всего лишь набор некоторых стандартных таблиц функций, которые система умеет передавать.

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

На самом деле, в Web-программировании именно так и было - все данные хранились на клиенте и при каждом обращении к серверу передавались на сервер, а потом обратно на клиента с новой версией страницы.
Потом появился ajax, когда программист выбирает, какие данные ему нужно отправить на сервер и что получить в ответ, не обновляя форму целиком.
А 1С у нас, на данный момент, на первом этапе.
(Хотя, вызовы "БезКонтекста" есть, но нет возможности собрать кастомизированный контекст).

(68) Это атавизм хотя бы по той причине, что с кроссплатформенностью у COM всё плохо. Да и сама Microsoft почти похоронила эту технологию.

(70) ajax не предусматривает stateful бекенда. А даже наоборот, потенциально позволяет разбить бекенд на кучу относительно независимых микросервисов.

(70) Почему на первом? 1С упирает на то, что они стараются гонять не все данные, а только изменения. Правда, типа не всегда это возможно. Контекст формы кастомизируется как угодно.
(71) Ок. Какие альтернативы для доступа к внешним библиотекам из скриптовых языков?

(73) В мире *nix как-то выходят из положения.

(74) Как? Консольными утилитами?

(75) Я бы сказал — успешно.

(76) Ручным плугом пахать тоже вполне успешно получается.

(74) Ну, выходят потоками - просто для передачи потока данных как-то нужно договариваться, что там передаётся, как раз COM-подсистема и являлась тем звеном, которое скрывало от пользователя механизм договорённости.
В глубине COM-механизма лежат или WM_COPYDATA или тот же TCP-тунель, а внутри одного процесса допустимы и прямые вызовы.
Главной отличительной особенностью от всего остального является механизм разделения объектов, когда сам объект остаётся на месте, а передаётся только его интерфейс, который как раз и есть stateless.

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

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

(71) Можно про похороны COM технологии Microsoft-ом подробнее?
А то разработчики ЯП в опасносте.

(68) OLE - это не COM.
1С не работает с OLE от слова "вообще".

(77) Да всё там нормально, просто там костыли другой системы.
Передачи данных напрямую от одного процесса другому нет ни там ни там. Проецирование файла в память, которое продвигает Microsoft, всё равно остаётся файлом на диске, а в Linux можно сделать виртуальный файл, когда каждая запись будет сопровождаться функцией получения данных с другой стороны.

(81) OLE - это надстройка над COM-подсистемой для организации общего интерфейса для пользователя.
Собственно говоря, для OLE нужны несколько классов, определённых в COM и реализация как со стороны клиента, так и со стороны сервера.

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

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

Microsoft все ширше и ширше продвигает COM из всех сил.

(83) Не стоит путать OLE с ActiveX. OLE - это прообраз ActiveX, работал только внутри продуктов MS Office и позже мутировал в ActiveX.

(85) На самом деле, java-классы можно рассматривать как некоторое подобие COM механизма.

(86) Наоборот ActiveX это часть OLE, так как ActiveX это реализация интерфейса IDispatch, который для OLE и не нужен.
OLE - это возможность внедрения и интеграции одного объекта в другом.

(87) Нет.
Я вооот про это:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd316908(v=vs.85).aspx

Microsoft говорит - используйте интерфейсы, а не экспортные функции DLL. Это началось с MS VISTA.
Все это поддерживается COM - механизмами, ибо будь иначе (без COM) - Microsoft бы как минимум дала бы CLSID для создания фабрик классов вручную. Да и ручное создание фабрик классов требует работы с указателями - что запрещено в "рассово" верных языках.

(88) IDispatch для OLE тоже нужен.

(89) Это ещё началось с Windows NT, когда было придумано так называемое "позднее связывание", когда мы не знаем самого объекта, а знаем только о его интерфейсах.

(91) Охохох... Я про козу, он - про ерему.

(90) Для внедрения или соединения объектов IDispatch не нужен, он будет нужен, когда мы заходим из приложения-владельца что-то с объектом сделать.

(92) Просто, подключение и вызов функции из DLL напрямую требуют имени DLL, её размещения и имени функции в DLL. Для COM-объекта же требуется только его GUID (точнее CLSID), что позволяет использовать разные версии объектов в одном приложении, что с DLL достаточно сложно.

(91) Я знаю, что такое интерфейсы.
Я говорю, что до ms vista WinAPI был реализован в виде экспортных функций dll-ок.
Когда появился Vista - весь новый функционал WINAPI стал реализовываться через COM.

(94) Ну и версионирование - тоже как плюс к COM.

(94) Ну вообще для COM объекта требуется только PROGID.

(95) На самом деле, сначала был некоторый базовый WinAPI, потом, с появлением Windows 2000 в нём появились функции с добавкой Ex, которые его немного расширили. Видимо, вторую добавку никто делать не захотел.

(97) ProgId это всего лишь способ отыскания ClassId, особенно, если посмотреть, что живёт в реестре в разделе ProgId.

(94) COM технология - это всего лишь:

1) Автоматическая загрузка DLL по хранимому пути в реестре.
2) Создание фабрики класса по хранимому CLSID в реестре.
3) Создание объекта и возврат его интерфейса.

Все это делается Windows автоматом просто по одному вызову
CoCreateInstance()

Но!

Ты можешь отказаться от этого (от COM) и самостоятельно загрузить dll, создать фабрику классов через DllGetClassObject() и создать экземпляр класса.

Для этого бы должен знать (и хранить):
1) Путь к библиотеке.
2) CLSID требуемого объекта.
3) CLSID фабрики классов (она фиксирована, ничего страшного)
4) Среда разработки умеет работать с указателями.

Гемморой.

Самое главное, что новый WinAPI требует новых сообщений, а их количество ограничено, поэтому, всё сводится к использованию WM_COPYDATA, а интерфейсы - это всего лишь механизм.
Опять же, один COM-сервер может прекрасно обслуживать все программы, тогда как DLL в каждый процесс будет внедряться своя.
Да и потом, директория WinSxS и всё, что с ней связано, объясняют, что с количеством Dll все просто запутались.

(99) CLSID и пути к dll. это 2 важных параметра. Ну и еще наличие библиотеки типов.

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

(103) Про библиотеку типов - просто к слову. Я знаю, что такое библиотека типов.

Давай, чтобы не возникало вопросов, я скину тебе поделку свою.

(100) Ну, просто можно самому заглянуть в реестр и найти там данные, система же их именно там и ищет.
Поскольку я на Си (а не Си++) писал COM-сервера, то я прекрасно знаю, что и где делает система, чтобы найти объект.

(104) Библиотека типов интересна, когда ты описываешь свои структуры для передачи данных - просто реализация IMarshal будет немного сложнее, чем описание типа.

(105) Можно и заглянуть. А можно вообще с реестром не работать.

(105) Все можно вытянуть из библиотеки типов, даже не занося данные о dll в реестр. Если разработчик потрудился написать эту бблиотеку типов.

(107) Ну, когда нужно загрузить объект, которого нет в реестре, то приходится это делать вручную, повторяя то, что делает система.
Причём, иногда можно создать объект и "подсунуть" его системе перед тем, как его получит другое приложение, стремящееся создать то, чего в реестре нет.

(109) Да, ты чертовски прав.

Вот и моя Нетленка так делает :-)

(108) Ну не всё, а просто получить ITypeInfo потом ITypeLib и дальше просто вызывать его методы.
То есть все слова о том, что есть Библиотека типов сводятся к реализации интерфейса ITypeLib.

(82) Что именно нормально? Я не настоящий сварщик. Какие в линуксе есть способы работать из скрипта с внешней библиотекой, кроме как через потоки ввода/вывода? А для этого нужна утилита, которая будет уметь эту библиотеку в потоки ввода/вывода.

(112) Здрастьте, приехали, а в Linux script, насколько я помню, на языке shell выполняется, и там можно только команды системы использовать.
Не забываем, что WScript.exe, на котором в Windows пишут сценарии, это всего лишь одна из реализаций некоторого вспомогательного объекта. В Linux для таких объектов есть язык Си, так как gcc компиллятор всегда в наличии.

(111) Я те скинул на почту, зацени.

(110) Просто, когда нужно было загрузить две версии одного и того же объекта (из разных Dll, но с одним кодом версии), то приходилось делать именно это.

(113) Кроме капитанских обрывков информации внятный ответ есть? Типа "нет, нету". Или "есть вот такой".

(114) Посмотрю, конечно.

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

(117) Да, я в курсе :-)

(116) В Linux вообще нет сценариев, где можно работать с объектами, в shell сценариях переменные хранят только строки.
Так что только командная строка.

(117) Правильные разработчики ВК в dllRegserver сначало пытаются писать в общий раздел, а если нет прав - в частный.

(119) Ну вот. Я и говорил о том, что с COM там сравнивать тупо нечего. А ты - "нормально там всё".

(118) Ты-то в курсе, а куча горе писателей COM-объектов - нет, вот и приходится запускать RegSvr32 под администратором, чтобы вписать объект в систему.

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

(121) Чем тебя не устраивает, скажем php и его модули.
Не забываем, что в php, например, можно параллельные потоки запускать, что в Windows сценариях и не снилось.
А вы COM. Под зад пинком этот COM, если предлагается многопоточность из коробки.

(120) В Windows также есть файл .manifest,
https://msdn.microsoft.com/ru-ru/library/1w45z383(v=vs.110).aspx
где можно описать вызываемые из кода объекты и их положение в dll, и система, прежде чем искать в реестре, будет искать в этих файлах.
Так что, вполне вероятно, что некоторые проблемы с использованием COM-объектов можно решить просто написанием этого файла (я, правда, не пробовал).

(124) Это работает для функции LoadLibraryEx

(125) А для GetClassObject нет ?

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

(126) Она использует в своей работе
coLoadLibrary() в которой нет флага поиска пути.
https://msdn.microsoft.com/en-us/library/ms886346.aspx

(128) Почему то меня поиск вынес на win ce, но я думаю, в обычных виндах - также.

(121) есть, например, https://ru.wikipedia.org/wiki/D-Bus

(130) О! Наконец-то ответ по существу.
Спасибо, буду знать.

(130) Это, скорее, реализация механизма, похожего на очередь сообщений в Windows.

(132) Не. MSMQ скорее всё же про межсистемное взаимодействие, чем про межпроцессное. И никаких плюшек близких к задачам COM базово не имеет.
А D-Bus в самом деле неплохо покрывает задачи COM, судя по описанию. Хотя в отличие от COM (в простейшем случае) подразумевает асинхронное взаимодействие, что усложняет.

(133) В COM тип взаимодействия выбирается из размещения объектов, если в одном потоке, то будут прямые вызовы, если нет, то будет асинхронное обращение с ожиданием.
Вот как раз ожидание в COM-взаимодействии и напрягает.

Кстати, у Microsoft ещё есть замечательные механизмы NamedPipe и MailSlot, которые позволяют процессам обмениваться данными.

(135) Эти механизмы (NamedPipe) дают фантастическое быстродействие в режиме "Процесс" - "Процесс".
Странно, что они не используются в кластере 1С.

(97) http://www.delphisources.ru/pages/faq/base/interface_idispatch.html

Если вспомнить Delphi и CreateOleObject
Com это IUnknown

https://ru.wikipedia.org/wiki/Microsoft_OLE_Automation

OLE Automation — технология компании Microsoft, позволяющая обращаться к COM-объектам из интерпретаторов скриптовых языков, таких, как VBScript (на настоящий момент поддержка обращений к OA-объектам есть в Windows-версиях всех популярных скриптовых языков).

История[править | править вики-текст]
Впервые появилась около 1993 как замена устаревшей возможности DDE_EXECUTE.

Среда программирования Visual Basic была практически полностью основана на OLE Automation, с такими типами данных, как String и Variant.

Объектами OLE Automation являются все элементы управления ActiveX (OCX-контролы). Свойства, методы и события этих компонент реализованы с помощью OLE Automation.

Также объектами OLE Automation являются многие популярные приложения, такие, как компоненты Microsoft Office. Это дает возможность запустить и управлять даннным приложением (например, Excel, например, сформировать программно таблицу, заполнить в ней ячейки и сохранить в файл) из скрипта, написанного на скриптовом языке.

Также объектами OLE Automation являются все тэги Dynamic HTML (при использовании Trident или же — вроде как, нужно проверить — Apple WebKit или Google Chrome).

Также на этой технологии основана WMI (ее слой, отвечающий за общение с клиентскими программами) и ряд административных утилит Windows, например, управление веб-сервером IIS.

http://compress.ru/article.aspx?id=10600&part=index21ext1

(138) Wmi основана на COM-сервере, обслуживающем запросы WMI.
Не надо путать OLE и COM - они очень похожи, просто OLE основана на COM-серверах, но COM значительно шире.

(136) Named-Pipe это некоторый упрощённый интерфейс для обмена поточными данными.
TCP-соединение между машинами бывает даже быстрее (так как named-pipe основан на IP-пакетах).

А в рамках одной машины быстрее всего оказывается технология SharedMemory, когда память одного процесса передаётся в другой.
Насколько я знаю, и в Windows и в Linux этот режим есть.
Только вот вопросы в его безопасности.

(139) В delphi COM более развит, чем в Visual Basic, так как можно и свои интерфейсы создавать (что в VB нельзя).

(134) Все зависит от аппартамета
http://www.introligator.org/articles/3/84

(141) Я к тому, что OLE Automation это и есть IDispatch

(142) Apartment и есть размещение (или окружение) как его называют.

143+ IConnectionPointContainer,IConnectionPoint

(143) Automation это раньше было DDE, а теперь COM-сервер с интерфейсом IDispatch.
Только там могут и другие интерфейсы использоваться (обычно два IDispatch в обе стороны - от управляющего команды управляемому и от управляемого события управляющему).

Процесс имеет один или несколько MTA апартаментов и ни одного STA. Эта модель называется моделью свободных потоков (free-threaded model). Для DLL-сервера в реестре будет записан ключ Threadingmodel=”Free”, а для EXE-сервера будет создан апартамент MTA. Клиенты могут вызывать любые методы объекта из любого потока в любое время. Объекты могут обрабатывать любое число потоков в любое время. Они должны защищать глобальные данные и данные экземпляров с помощью критических секций или каким-либо другим методом, защищающим некоторую последовательность кода. Клиенты программируются легко, однако объекты более сложны в разработке. Используется в первую очередь в распределенных средах DCOM Both. Модель смешанных потоков (both-threded model): имеются MTA и STA апартаменты. Для DLL-сервера в реестре будет записан ключ Threadingmodel=”Both”, а для EXE-сервера будет создан апартамент MTA. Объекты могут поддерживать клиентов, которые используют модели apartment или free. Максимум производительности и гибкости. Клиенты могут использовать одно-поточную или многопоточную модель для повышения производительности Neutral. Модель нейтральных потоков (neutral-threaded model), близкая к модели Both. Для DLL-сервера в реестре будет записан ключ Threadingmodel=”Neutral”, а для EXE-сервера будет создан апартамент MTA
Модель нейтральных потоков отличается от модели смешанных потоков тем, что, во-первых, для ее поддержки нужна COM+, и, во-вторых, она несколько упрощает синхронизацию потоков. Суть синхронизации заключается в том, что если какой-либо клиент вызвал метод объекта, то другой клиент не сможет вызвать этот же метод до тех пор, пока метод не завершится. Если все методы работают только со «своими» данными, то в этом случае отпадает необходимость и в синхронизации доступа к полям объекта.

Есть ещё IDataObject.

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

(146) Я это прекрасно понимаю. Просто я к васшему Хэдджехогсом по поводу ОЛЕ,СОМ, АктивИкс

(147) И осталось добавить, что OLE подсистема работает в Single Thread Apartment.

(149) ActiveX изначально вообще были 16-битные, тогда как COM-объекты сразу пошли в 32-бита.

(150) Нет. IDispatch ничем не отличается от COM. Другое дело если это касается контролов
(151) https://ru.wikipedia.org/wiki/ActiveX
Впервые эта технология была внедрена в 1996 году компанией Microsoft как развитие технологий Component Object Model (COM) и Object Linking and Embedding (OLE) и теперь она широко используется в операционных системах семейства Microsoft Windows[источник не указан 1028 дней], хотя сама технология и не привязана к операционной системе.

Множество приложений для Microsoft Windows, включая приложения самой компании Microsoft, такие, как Internet Explorer, Microsoft Office, Microsoft Visual Studio, Windows Media Player, используют управляющие элементы ActiveX, чтобы реализовать набор функциональных возможностей и в дополнение инкапсулировать их собственный функционал в управляющие элементы ActiveX, чтобы предоставить возможность встраивать их в другие приложения.

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

мне тема нравиться. ушли хер знает в какие дебри

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

(155) Интерфейс, это не реализация класса - это таблица функций. Про то, что он является классом с виртуальными функциями уже подумали потом.

(156) это что может должно быть в наследование . верно же ?

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

(157) может ты еще знаешь wicket+java?

Например, в Си пишется так:
typedef struct tagInterfaceUnknown
{
struct tagInterfaceUnknownVtbl*lpVtbl;
}IUnknown;
То есть интерфейс, это структура, содержащая ссылку на таблицу виртуальных функций.

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

(159) C java я как-то не подружился, так как не перевариваю языки, где нельзя принудительно управлять памятью.

(160) Мало того например в Delphi по отрицательному смещению хранятся ссылки на виртуальные методы ксласса (static) и конструктора
http://rsdn.ru/article/Delphi/delphiabs.xml


{Virtual method table entries }

  vmtSelfPtr           = -76;
  vmtIntfTable         = -72;
  vmtAutoTable         = -68;
  vmtInitTable         = -64;
  vmtTypeInfo          = -60;
  vmtFieldTable        = -56;
  vmtMethodTable       = -52;
  vmtDynamicTable      = -48;
  vmtClassName         = -44;
  vmtInstanceSize      = -40;
  vmtParent            = -36;
  vmtSafeCallException = -32;
  vmtAfterConstruction = -28;
  vmtBeforeDestruction = -24;
  vmtDispatch          = -20;
  vmtDefaultHandler    = -16;
  vmtNewInstance       = -12;
  vmtFreeInstance      = -8;
  vmtDestroy           = -4;

  vmtQueryInterface    = 0;
  vmtAddRef            = 4;
  vmtRelease           = 8;
  vmtCreateObject      = 12;



Как интересно! Часть из них меньше нуля. Судя по именам констант, вплоть до vmtAfterConstruction (смещение -28) расположены указатели на различные интересные данные. Затем идут указатели на виртуальные методы, декларированные в самом TObject: AfterConstruction, BeforeDestruction, Dispatch, DefaultHandler, NewInstance, FreeInstance, Destroy. Затем идут методы с неотрицательными смещениями. Таким образом, указатель, расположенный в начале объекта, ссылается куда-то «в середину» VMT. И эта середина – ровно то место, с которого будут располагаться виртуальные методы, объявленные в классах-потомках. Из названий констант vmtQueryInterface, vmtAddRef и vmtRelease ясно, зачем так сделано – иначе в потомках TObject было бы невозможно реализовать интерфейс IUnknown.

Итак, 4 байта, полученных при вызове TObject.ClassType, указывают в начало таблицы виртуальных методов, декларированных в потомках TObject. Этот вывод можно считать «безопасным» до тех пор, пока Delphi поддерживает совместимость с COM.

(162) Это называется Хак - чтобы не портить совместимость со стандартными классами "умные программисты" придумали, чтобы их методы лежали в таблице ниже основных, и передавать указатель на основной.
Также, например, работают SystemString (BSTR), когда передаётся указатель на строку, а перед ней ещё кто-то живёт.
Да и с оконными классами тоже есть отрицательные смещения.

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

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

(163) В Net для каждого класса генерится одна VMT где для каждого интерфейса своё смещение

В этом дизайне каждому интерфейсу во время его загрузки присваивается уникальный номер интерфейса (читай порядковый номер интерфейса с момента старта программы — прим. AVK). Каждый класс, который реализует один или несколько интерфейсов, имеет вторичную таблицу интерфейсов, или ITable, которая доступна посредством косвенной ссылки из стандартной VTable.
Вызов происходит посредством перенаправления, используя номер интерфейса.Он в свою очередь указывает назад, на секцию нормальной VTable в которой расположены методы, реализующие интерфейс. Конечно, ITable невероятно избыточна. Используемый класс может реализовывать только интерфейсы с номерами 1003 и 2043. Мы нуждаемся только в двух слотах для него, так что будет черезвычайно расточительно тратить 2044 слота (2044 потому что класс не может реализовывать интерфейсы, которые еще не загружены, поэтому реализовать интерфейс с номером, большим 2043 он так же не может. Отсюда требуемый размер ITable — прим. AVK). Следовательно ключевой аспект этого дизайна это то, что все ITable редко расположены в единственном общем хипе.