Обзор объектных систем

Содержание

  1. Введение
  2. Текущее состояние объектных систем
    1. COM
    2. XPCOM
    3. VirtualBox XPCOM
    4. GObject
    5. Objective-C runtime
    6. SOM
    7. NOM
    8. WinRT
    9. Итоговая таблица
    10. Другие объектные системы
  3. Мысли на будущее
    1. Почему C++ не такой же простой, как C?
    2. Common Lisp Object System
    3. Импорт компонент
  4. Источники

Введение

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

— Олег Горский, технический директор ООО «Кубикс»

Во времена 80х и начала 90х различия между такими языками, как C, Pascal и Fortran, были не столь пагубными для взаимной интеграции, как различия между современными ЯП. Можно было написать часть кода на Fortran, подключить пару библиотек на C и скомпилировать всё в рамках единой программы, основным языком которой является Pascal. Эта совместимость осталась далеко в прошлом, и не в последнюю очередь это можно связывать с малой популярностью объектных систем. Под объектными системами следует понимать не связанные с каким–либо одним языком программирования библиотеки и инструменты трансляции IDL (interface definition language) в заглушки на разных языках программирования. Только посредством подобных библиотек и инструментов (каркасов, frameworks) возможно комфортное сосуществование разноязыковых компонент. Кроме того, подобные системы дают возможность изменять реализацию динамических библиотек, не требуя перекомпиляции пользователей библиотек, и это один из мотивов существования объектных систем даже в условиях недостаточной конкуренции на арене языков программирования.

Текущее состояние объектных систем

Kраткости ради для сочетание «объектная система» в дальнейшем будет использовано сокращение *OM, так как по меньшей мере 4 из них имеют такой шаблон аббревиатуры: COM, XPCOM, SOM, NOM.

Средств межкомпонентного и межъязыкового взаимодействия, на самом деле, в избытке (и это тоже отчасти проблема), но, если предъявить некоторые, с виду банальные требования, круг существенно сужается. Автор уделяет основное внимание следующим критериям *ОМ:

  1. Внутрипроцессная взаимоинтеграция. Только–сетевые средства взаимодействия (CORBA, Thrift), не рассматриваются.
  2. Отсутствие требований компиляции в специальный формат какой–либо виртуальной машины (JVM, CLR).
  3. Объектные системы, встроенные в компилятор какого–либо языка программирования и не поддерживающие объявление сущностей (классов, интерфейсов) из другого языка программирования, не рассматриваются.

COM

Как самая первая и самая известная объектная система, будет рассмотрена в первую очередь.

COM (Component Object Model)1 разработан в Microsoft в рамках развития DDE и OLE. Характерными особенностями являются:

  • Работа с объектами через так называемые интерфейсы, либо через специальный интерфейс IDispatch для динамической диспетчеризации.
  • Отсутствие поддержки наследования реализации между компонентами разных сторон.
  • Хитросплетение межпоточной синхронизации для совместимости с Visual Basic 2.
  • Одиночное (а не множественное) наследование для интерфейсов.
  • Поддержка исключительных ситуаций (exceptions)34.
  • Глобальный контекст зарегистрированных классов в реестре. Экземпляры зарегистрированных классов создаются по CLSID5 или по строковому идентификатору (ProgID)6.
  • Межпроцессное взаимодействие (DCOM) в пределах компьютера или сетевого домена.

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

COM тесно связан с OS Windows, однако подмножества COM можно встретить на VMS и Mac OS X. И, конечно, на платформе Wine.

XPCOM

Несмотря на отсутствие поддержки наследования, объектные системы, использующие интерфейсы, были шагом вперёд по сравнению с неоднозначным описанием API в заголовочных файлах C. Автор сталкивался с разнообразными проблемами, делая высокоуровневые привязки для библиотек на языке C. Например, при создании привязок для libyaml на Delphi: входной строковый аргумент может иметь формальный тип char *, и нет определённости, во что следует преобразовывать пустую строку: в нулевой указатель или в ненулевой указатель на нулевой байт? Можно ли делать повторную деинициализацию структуры, если комментарий гласит, что аргумент будет уничтожен в любом случае? Неправильные решения приводят к неработоспособности толстой привязки. Разбор каждого нюанса отнимает время.

*OM дают однородные ответы на подобные низкоуровневые вопросы, и востребованы не только в OS Windows. Популярным кроссплатформенным аналогом COM является XPCOM (Cross Platform Component Object Model)7. XPCOM разработан в Netscape, в данный момент поддерживается Mozilla Foundation. Особенностями XPCOM являются:

  • Аналогично COM, работа с объектами через интерфейсы.
  • Аналогично COM, отсутствие наследования реализации.
  • Отсутствие неявных прокси для межпоточной синхронизации8.
  • Аналогично COM, одиночное наследование интерфейсов9.
  • Чуть более полная по сравнению с COM поддержка исключительных ситуаций10.
  • Локальный контекст зарегистрированных классов в файлах приложения. Аналогично COM, экземпляры зарегистрированных классов создаются по CID или строковому идентификатору (ContractID)11.
  • Межпроцессное взаимодействие не поддерживается средствами XPCOM (но принципиально возможно)
  • Несовместимость с COM, а также между компонентами разных приложений.

Встречается, главным образом, в продуктах Mozilla (Firefox, Thunderbird, Sunbird), либо в продуктах третьих сторон на фундаменте XULRunner (Komodo, SongBird, InstantBird). Во всех этих продуктах навязанный способ использования платформы предполагает реализацию логики пользовательского интерфейса на JavaScript, который посредством XPConnect создаёт экземпляры объектов и служит прослойкой между XUL и объектами XPCOM, такими, как TCP сокеты. Это отличается от того, как делаются GUI приложения на других библиотеках. Поэтому, например, можно встретить примеры перевода пользовательского интерфейса с wxWidgets на Qt, но нет примеров перехода на XULRunner и XPCOM. На платформе XULRunner доступно большое количество полезных классов: для работы с сетью, для криптографии, для работы с файлами и др., но из–за своих особенностей XPCOM остаётся вещью в себе, используемой только в плагинах для продуктов Mozilla, либо в приложениях, изначально разрабатываемых на платформе XULRunner.

VirtualBox XPCOM

Среди прочих приложений, использующих XPCOM, выделяется VirtualBox. VirtualBox написан таким образом, что использует Microsoft COM на OS Windows и XPCOM — на остальных OS12. Кодовая база XPCOM при этом немного отличается от используемой в продуктах Mozilla. В VirtualBox XPCOM реализовано межпроцессное взаимодействие, необходимое для управления виртуальными машинами, и эти изменения не присутствуют в кодовой базе Mozilla XPCOM. Кроме того, как пишут разработчики VirtualBox, каждое приложение XPCOM содержит свою, отличающуюся версию XPCOM13.

GObject

С GObject (GLib Object System)14 начинается обзор объектных систем с поддержкой наследования кода между компонентами.

GObject — довольно общее понятие. Библиотека GLib позволяет реализовать альтернативные иерархии классов15, но рассмотрены будут только те способы использования, которые реально применяются в прикладных программах вроде GIMP и плагинов для GIMP. Каждый класс представлен двумя структурами данных: для класса и для экземпляров класса16. Структура данных класса при этом обычно используется для таблицы виртуальных методов, а структура данных экземпляра класса — для полей объекта. Текущая реализация GObject страдает от следующих недостатков:

  • При наследовании одного класса от другого, код которого находится в другой динамически подключаемой библиотеки, в будущем становится невозможно поменять размеры и формат структур данных класса и объекта.
  • Нельзя добавить новые виртуальные методы, что для классов гораздо критичнее, чем для интерфейсов.
  • Нельзя добавить новые поля, хотя последнюю проблему решают резервированием специального поля для приватных данных. По одному полю для каждого следующего наследника.
  • В отличие от остальных *OM, в GObject допускаются статические методы.
  • Начиная с версии 2.4 (2004й год), в GObject поддерживаются интерфейсы, но без поддержки наследования17.
  • Не используется IDL.

Таким образом, можно сказать, что GObject копирует устройство объектных систем внутри языков программирования, таких, как Delphi, C++, Ada вместе с их недостатками применительно к многоязыковым и многокомпонентным условиям исполнения. Обходные пути решают проблемы лишь удовлетворительно. Штатного механизма модификации родительского класса, не затрагивая дочерние, нет.

Objective-C runtime

Рассмотрение библиотеки времени выполнения Objective-C18 будет как нельзя кстати, ведь, в отличие от других языков программирования, Objective-C runtime не привязан жёстко к языку Objective-C. Библиотека Objective-C runtime предоставляет полный набор API для работы с системой классов: создание, вызовы, запрос на принадлежность и прочие, и этот API, конечно, доступен из любого ЯП, в котором возможно вызывать внешние функции на C19. Примечательной особенностью Objective-C и его runtime является способ вызова методов: специальная функция objc_send исследует таблицу вызовов классов от потомка к родителю в поисках подходящего селектора. Селектор — аналог имени метода в других языках. Такое устройство позволяет добавлять в будущем новые поддерживаемые селекторы, не требуя перекомпиляции кода пользователей классов, в том числе в случаях, когда от классов наследуются другие классы в компонентах третьих сторон. Именно этим Apple и пользуется, добавляя функционал в новых версиях Mac OS X. Селекторы можно объединять в протоколы (аналог интерфейсов в других *ОМ). Так как протокол — это всего лишь множество селекторов, не требующее иметь какой–либо порядок в структурах данных, как в других *OM, для протоколов доступно множественное наследование20. Ещё одной особенностью Objective-C и его runtime является наличие подробной метаинформации о методах и возможность обработать неподдерживаемый селектор. Это существенно облегчает создание прокси для удалённых объектов.

Недостатками же этой объектной системы являются:

  • Аналогично GObject, требование неизменности размера экземпляра класса после публикации компонента одной стороной другой стороне. И аналогичный обходной путь: приватное поле с указателем на объект с приватными данными.
  • Экзотический способ именования методов селекторами, заимствованный из SmallTalk. Селектор отличается от просто имени метода тем, что строки селектора перемежаются с аргументами, но при этом составляют единое целое. Вызов может выглядеть как [myString stringByPaddingToLength: 9 withString: @"." startingAtIndex:0], при этом селектором является "stringByPaddingToLength:withString:startingAtIndex:". Это затрудняет создание мостов для других языков программирования. В разных привязках используются разные способы преобразования селектора в обычное имя метода.
  • Вместо IDL используются заголовочные файлы Objective-C, которые потенциально могут содержать любые определения, допустимые в C. Их сложнее обрабатывать, чем IDL. Для полноценного использования классов, написанных на языках программирования, отличных от Objective-C, в Objective-C нужно предоставить заголовочные файлы именнo для этого языка программирования.

Подводя итог, можно сказать, что среди используемых *ОМ, Objective-C runtime лидирует по гибкости, но использование в других языках программирования даёт лишь потенциальную гибкость. Практически, для использования наравне с Objective-C требуется решать дополнительные проблемы. По иронии, если исключить Objective-C из рассмотрения, проблем становится гораздо меньше, так как только компилятору Objective-C требуется на этапе компиляции знать размер экземпляров родительских классов. Так как для других ЯП эта *OM не является встроенной, мосты для Objective-C уже содержат код, определяющий размер экземпляров класса во время исполнения, а не во время компиляции.

SOM

IBM SOM (System Object Model)21 — пожалуй, самая интересная и самая загадочная объектная система. Объектные системы неспроста выстроены именно в таком порядке: сначала нет наследования и нет проблем, с ним связанных. Потом наследование есть, но гибкость весьма хромает: тяжело изменять как набор методов родительского класса, так и размер экземпляра родительского класса. Потом половина этих проблем решается, вторая половина не решена. Как можно догадаться, SOM является венцом творческой мысли. SOM изначально задумывалась как средство взаимодействия разноязыковых компонент (IBM поддерживает C, C++ и SmallTalk), с соответствующими инженерными решениями. В частности, интерфейсы объявляются на языке IDL, на основе которых специальные инструменты создают мосты для выбранного языка программирования. SOM создавался примерно в одно и то же время, что и COM, и эти объектные системы часто можно видеть в сравнении друг с другом22, чего нельзя сказать про сравнение, проводимое автором для остальных *OM.

К сожалению, познакомиться с SOM поближе автору, да и любому заинтересованному человеку практически невозможно. Примерно в 1997м году IBM сворачивает разработку SOMObjects Developer Toolkit. Это происходит наряду с необъяснимым убийством, не сказать иначе, OS/2. Самая последняя версия SOMObjects DTK, 3.0, была доступна для Windows NT (!!!), OS/2 и AIX. Её можно было загрузить бесплатно с сайта ibm.com, но в Интернете не осталось ни одной копии версии для Window NT. Автор тщетно пытался связаться с различными людьми, связанными с этой разработкой, как с теми, кто обсуждал в Usenet, так и с разработчиками OpenDoc, аналога OLE, основанном на SOM.

Как альтернатива, была рассмотрена возможность использования SOM для OS/2 или AIX в эмулируемом окружении (в этих OS SOM встроенный). Эмуляция OS/2 являлась подсистемой Windows NT. Также, существуют расширители DOS, поддерживающие исполняемые файлы OS/2. Но на поверку версия OS/2, которая поддерживается этими эмуляторами, ниже OS/2 3.0, требуемой для работы библиотеки и инструментария SOM. Полная эмуляция виртуального компьютера с установленной OS/2 потребует особой виртуальной машины в силу особенностей ядра OS/2. Сложность эмуляции настолько велика, что была основана целая компания Parallels, для эмуляции OS/2 на современном оборудовании по заказу одного московского банка. Что касается AIX, у AIX существует версия для архитектуры x86, но версия, недостаточная для SOM. Будущие версии AIX разрабатывались для PowerPC. Соответственно, для экспериментов с SOM на AIX потребуется эмулировать PowerPC. Ещё одной призрачной возможностью автору видится покупка старых книг про SOM с дискетой или CD-ROM, на которых было бы ожидаемо встретить SOMobjects DTK, бывший в те времена свободно распространяемым, но подобные эксперименты дорого стоят. Было бы не менее логично обнаружить SOMobjects DTK в дистрибутиве IBM VisualAge for C++, но его там нет.

Периодически в Интернете обращают внимание на SOM 23 24. Даже, если и удалось кого–то заинтересовать, этот интерес разбивается о недоступность инструментария. Перефразируя английскую поговорку, файлы говорят громче слов. Если бы разработчики получили бы в распоряжение хотя бы версию для Windows NT и попользовались бы в своих проектах, матрица идеологии SOM со всеми подробностями отпечаталась бы в сознании, а отсюда недалеко до качественного клона, сверяемого с оригиналом на совместимость, с открытыми исходными кодами. Файлы получить не удалось, эмуляция слишком требовательная, чтобы расчитывать на то, что интересующиеся любители пойдут достаточно далеко, чтобы установить, настроить и попытаться что–то написать в незнакомой OS.

Факты о SOM, которые удалось установить, опираясь на документацию25:

  • Работа с объектами только через интерфейсы, но у классов один из интерфейсов объявляется главным.
  • Множественное наследование как интерфейсов, так и реализаций.
  • Использование CORBA для межпроцессного взаимодействия. Компонент, отвечающий за это, называется DSOM, аналогично DCOM от Microsoft.
  • IDL для описания классов и интерфейсов.

NOM

NOM (Netlabs Object Model)26 — попытка сделать кроссплатформенный открытый клон SOM. Проект не завершён и для знакомства с SOM не годится. Инженерные решения отличаются от принятых в SOM, и насколько именно, сложно определить. Проект указан для полноты, аналогично VirtualBox XPCOM.

WinRT

WinRT (Windows Runtime)27 — новейшая разработка Microsoft, доступная только начиная с OS Windows 8. По этой причине автор не смог ознакомиться с WinRT ближе, и обзор будет тоже поверхностный. WinRT базируется на технологиях COM и .NET. Описания классов и интерфейсов кодируются в некоем двоичном формате, идентичном формату метаданных .NET, таким образом, давая возможность использовать уже существующие утилиты для доступа к метаданным. Соответственно, и свойства этой объектной системы наследуются от .NET:

  • Одиночное наследование классов, множественное наследование интерфейсов.
  • Обобщённые классы, интерфейсы и методы
  • Взаимоинтеграция кода на родных языках программирования и на ЯП для платформы .NET
  • C++/CX — особое расширение языка C++, дающее непосредственный доступ к возможностям WinRT, без дополнительных инструментов генерации кода или метаданных.
  • Аналогично .NET, сущности группируются в многоуровневые пространства имён.
  • Аналогично .NET, типы–значения (структуры, записи), отличающиеся от типов–ссылок на классы и интерфейсы.

Казалось бы, вот он, Золотой Грааль, технология, которую ждали пятнадцать лет. Однако, те, кто поработал с этой технологией поближе, пишут тревожные комментарии. Если изучать только официальную документацию (PlatformSDK, MSDN), многие существенные моменты упускаются, потому что всё само работает. Например, в описании принципов работы исключений на Win32 зачем–то даются примеры на Microsoft C и ни одного примера на ассемблере. Вряд ли кто–то открывает такие технические разделы, чтобы уточнить правописание слова catch. То же касается и WinRT. Вот, что отмечают люди, не аффилированные с Microsoft 28 29 :

  • Конечные узлы пространств имён не закрыты после их объявления. Другие файлы метаданных могут объявлять дополнительные классы в чужих пространствах имён. Или, лучше сказать, пространства имён не имеют соответствия 1:1 модуль–файл, как это сделано в нормальных языках программирования вроде Ada, Delphi, Dylan, не говоря уже о скриптовых, как Python. Соответственно, при попытке интуитивно понятным образом спроецировать API Windows 8 на Delphi (основной язык–первопроходец WinRT не от Microsoft) обнаруживается, что неоднозначное соответствие модуль–файл активно применяется не где–то у горе–разработчиков третьих сторон, а прямо в Windows 8 API, и как обходное решение, пространства имён не проецируются на пространства имён Delphi, а точки заменяются на знаки подчёркивания. В будущем, возможно, проецирование будет сделано правильно, просто для рассыпанного по разным файлам Windows 8 API нужно будет сделать особую обработку, несколько файлов в один приём.
  • Обобщённые интерфейсы, будучи конкретизированы, как и любые другие интерфейсы, имеют свой GUID, который можно вычислить, используя API, доступное только в Windows 8. Алгоритм, по которому вычисляется GUID конкретизированного интерфейса, не опубликован. Соответственно, даже скомпилировать некоторые вещи невозможно, не имея доступ к Windows 8.
  • И, наконец, после выхода Delphi XE3, разочаровавшего отсутствием поддержки WinRT, выясняется что приложения на любом языке программирования, использующие WinRT, но не написанные с использованием компиляторов производства Microsoft, могут работать только на компьютерах разработчиков. При публикации в магазин приложений выполняется проверка на использование запрещённых вызовов WinAPI, таких, как выделение памяти или отлов исключений, без которых невозможно обойтись. Приложения, собранные одним компилятором Microsoft C++, не вызывают эти API напрямую, а используют динамическую библиотеку VC++ RTL DLL, и поэтому проходят проверку. Для других языков программирования полноценный доступ к WinRT закрыт сколь угодно долго, пока в Microsoft не займутся этим вопросом. Если это вообще случится.

Итоговая таблица

ХарактеристикиCOMXPCOMVBox
XPCOM		GObjectObjective-C
runtime		SOMNOMWinRT
IDLдададанетнетдадада (.winmd)
наследование интерфейсов1110MMMM
наследование классов00011MM1
гибкость размера
объекта базового класса		н/пн/пн/пнетнетдадада
гибкость набора методов
базового класса		н/пн/пн/пнетдададада
межпроцессное взаимодействиеDCOMнетданетNSProxyDSOMнетда (.NET)
обобщённые классы, интерфейсынетнетнетнетнетнетнетда

Другие объектные системы

Помимо рассмотренных, существуют, например, UNO (Universal Network Objects)30 в OpenOffice.org и OW2 Fractal31. Характерной особенностью является отказ от какого–либо общего интерфейса нижнего уровня. Если в COM объекты реализуют интерфейсы и работают с другими объектами через интерфейсы, то в UNO разноязыковые компоненты взаимодействуют посредством механизмов, предоставляемых выбранным языком программирования, а обёртки (созданные из IDL) умеют транслировать вызовы в другие языковые окружения. При таком подходе разноязыковые компоненты оказываются разделёнными даже больше, чем в COM. Механизма наследования кода между разными компонентами не предусмотрено.

Мысли на будущее

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

Почему C++ не такой же простой, как C?

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

Для начала следует вернуться к языку C и его кажущейся простоте. Простота языка C обманчива и является следствием того, что при рассмотрении компиляторов этого языка упускается из виду источник простоты: компоновщик. Компоновщик сложный! Что делает обычно компоновщик? Берёт фрагменты кода и данных, размер которых не был известен при компиляции каждой другой части, и сопоставляет строки в таблицах импорта со строками в таблицах экспорта. То есть, при компиляции одного модуля адреса функций в других модулях неизвестны. Вместо неизвестного адреса компилятор делает запись в таблице импорта, а компоновщик затем подставляет нужный адрес. Итак, компоновщик умеет компоновать объектные модули в исполняемый файл, заменяя строки на адреса, грубо говоря. А компилятор C умеет делать эти импорты и экспорты, и то, что можно сделать на языке C, ненамного дальше уходит этих умений. Вся модульность в C обеспечивается в большей степени компоновщиком, нежели компилятором. Компилятор и компоновщик как зеркальные отражения друг друга.

Что сделал Страуструп не так, что C++ по своим свойствам так сильно отличается от C? Почему объектные файлы разных компиляторов практически несовместимы? Потому что баланс был нарушен. Компилятор был изменён, а компоновщик остался прежним. Даже, если не ставить целью поменять компоновщик третьей стороны, можно добавить дополнительный этап инициализации после того, как сделал свою работу обычный (плоский) компоновщик.

Предположим, мы задались целью расширить язык C таким образом, чтобы не возникало проблем, как в GObject и Objective-C runtime: в родительские классы должна быть возможность добавлять и поля, и методы. Итак, на этапе компиляции точные размеры ни таблицы виртуальных методов, ни экземпляров класса неизвестны. Какой–то другой, отличный от компилятора, инструмент начинает свою работу, когда размеры и набор методов стали точно известны. Так как стало известно, каковы размеры каждого базового класса и сколько байт добавляет к размеру экземпляра каждый из потомков, нужно эти размеры вписать в таблицы размеров экземпляров классов. Далее, предположим, что методы идентифицируются именем класса и именем метода, и нужно под каждый известный метод разметить таблицу виртуальных методов и вписать смещения в ещё одну таблицу смещений внутри таблиц виртуальных методов. Всё это очень начинает напоминать работу обычного (плоского) компоновщика с той разницей, что в нашем случае компонуются не фрагменты статической памяти, а прообраз создаваемых в будущем объектов в динамической памяти. Но принцип тот же.

Чтобы расширить C объектно–ориентированным программированием, сохранив его кажущуюся простоту, нужно также расширить и компоновщик, сделав его объектно–ориентированным компоновщиком. Если все участники используют один и тот же объектно–ориентированный компоновщик, они получают то же удобство взаимодействия, которое имели в 80х годах от обычного (плоского) компоновщика при процедурном подходе. Рассматриваемые объектные системы в той или иной мере и пытаются быть тем самым объектно–ориентированным компоновщиком.

Common Lisp Object System

Помимо вышеуказанных объектных систем, возможно, будет нелишним ознакомиться с CLOS и MOP. Изучить CLOS автор рекомендует, используя ЯП Dylan 32.

Импорт компонент

Даже, если появляется новая объектная система, есть проблема с отсутствием кода, предоставляющего компоненты для этой объектной системы. Первым решением является создание мостов к другим *OM. Это не очень отличается от создания привязок для различных языков программирования. Вторым возможным решением будет использование инструментов создания привязок для создания мостов. Например, Qt не является полноценной объектной системой, но для него есть привязки на многих языках программирования. Любая из привязок содержит общий код, специфичный для языка программирования и выбранной библиотеки и однородный код, созданный автоматически на основе метаданных в каком–либо формате. В случае, например, с wxWidgets, метаданные в формате IDL или XML, не предоставляются, но привязки, тем не менее, сделаны для многих языков программирования благодаря SWIG33. SWIG читает заголовки на C или C++, и в заголовках можно иногда встретить дополнительные инструкции для SWIG, управляющие механизмом создания привязок. Если такие инструкции уже есть, они пригодились бы и для импорта компонент в новую объектную систему.

Источники

  1. ^ https://www.microsoft.com/com/default.mspx
    "COM: Component Object Model Technologies"
  2. ^ http://www.winehq.org/docs/winedev-guide/dcom-1#AEN4033
    "A brief introduction to DCOM in Wine", раздел 10.2.13. Message filtering and re-entrancy
  3. ^ http://msdn.microsoft.com/en-us/library/windows/desktop/ms221062%28v=vs.85%29.aspx
    "MSDN: Returning Error Information"
  4. ^ http://msdn.microsoft.com/en-us/library/windows/desktop/ms221133%28v=vs.85%29.aspx
    "MSDN: EXCEPINFO structure"
  5. ^ http://msdn.microsoft.com/en-us/library/windows/desktop/ms686615%28v=vs.85%29.aspx
    "MSDN: CoCreateInstance function"
  6. ^ http://msdn.microsoft.com/en-us/library/windows/desktop/ms688386%28v=vs.85%29.aspx
    "MSDN: CLSIDFromProgID function"
  7. ^ https://developer.mozilla.org/en-US/docs/XPCOM
    "Mozilla Developer Network: XPCOM"
  8. ^ https://www.ibm.com/developerworks/webservices/library/co-xpcom/#h0
    "XPCOM Part 1: An introduction to XPCOM", раздел Microsoft COM and XPCOM
  9. ^ https://developer.mozilla.org/en-US/docs/XPIDL#Interfaces
    "Mozilla Developer Network: XPIDL", раздел Interfaces
  10. ^ https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIException
    "Mozilla Developer Network: nsIException"
  11. ^ https://developer.mozilla.org/en-US/docs/Creating_XPCOM_Components/An_Overview_of_XPCOM#XPCOM_Identifiers
    "An Overview of XPCOM", раздел XPCOM Identifiers
  12. ^ https://www.virtualbox.org/manual/ch11.html
    "VirtualBox programming interfaces"
  13. ^ https://www.virtualbox.org/wiki/Developer_FAQ
    "VirtualBox Developer FAQ"
  14. ^ http://developer.gnome.org/gobject/stable/
    "GObject Reference Manual"
  15. ^ https://en.wikipedia.org/wiki/GObject#Fundamental_types
    "GObject в Wikipedia", раздел Fundamental types
  16. ^ http://developer.gnome.org/gobject/stable/gtype-instantiable-classed.html
    "Instantiable classed types: objects"
  17. ^ http://developer.gnome.org/gobject/stable/gobject-Type-Information.html#G-TYPE-IS-INTERFACE:CAPS
    "Type Information", раздел G_TYPE_IS_INTERFACE()
  18. ^ https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Introduction/introObjectiveC.html
    "The Objective-C Programming Language"
  19. ^ https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ObjCRuntimeRef/Reference/reference.html
    "Objective-C Runtime Reference"
  20. ^ https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocProtocols.html
    "Protocols", раздел Protocols Within Protocols
  21. ^ https://en.wikipedia.org/wiki/System_Object_Model
    "IBM System Object Model"
  22. ^ http://web.archive.org/web/20080829223607/http://www.byte.com/art/9401/sec8/art7.htm
    "To Inherit or Not to Inherit?"
  23. ^ http://www.pcweek.ru/themes/detail.php?ID=108316
    "Лучшее из OS/2 на платформе Linux"
  24. ^ https://www.linux.org.ru/news/opensource/2332319
    "OS/2 Open Source: попытка №2"
  25. ^ ftp://ftp.software.ibm.com/publications/clubod/som30/index.html
    "IBM SOMobjects Developer's Toolkit Version 3.0 for Windows NT, OS/2 Warp, and AIX Documentation"
  26. ^ http://svn.netlabs.org/v_nom
    "NOM the Netlabs Object Model"
  27. ^ http://msdn.microsoft.com/en-us/library/windows/apps/br211386.aspx
    "Getting started with Windows Store apps"
  28. ^ http://www.thomgerdes.com/2011/12/winrt-internals-winmd-files.html
    "WinRT internals: WinMD files"
  29. ^ http://www.deltics.co.nz/blog/?p=1080
    "Why Delphi Cannot (currently) Support WinRT"
  30. ^ http://wiki.openoffice.org/wiki/Uno
    "UNO: Universal Network Objects"
  31. ^ http://fractal.ow2.org/
    "The Fractal Project"
  32. ^ http://opendylan.org/books/drm/Classes
    "The Dylan Reference Manual: Classes"
  33. ^ http://www.swig.org/
    "SWIG, Simple Wrapper Interface Generator"
Код для вставки: :: :: :: ГОСТ ::
Поделиться: //