Каким образом gobject облегчает связывание?

На официальном сайте gobject можно прочитать:

GObject и его низкоуровневая система типов GType используются GTK+ и большинством библиотек GNOME для предоставления:

  • объектно-ориентированные API на основе C и
  • автоматические прозрачные привязки API к другим компилируемым или интерпретируемым языкам

Первая часть мне кажется понятной, а вторая нет.

Действительно, говоря о gobject и связывании, часто вводится понятие gobject-introspection, но, насколько я понимаю, gobject-introspection можно использовать для создания .gir и .typelib для любой документированной библиотеки C, а не только для gobject-based библиотека.

Поэтому мне интересно, что делает gobject особенно удобным для связывания.


gobject gobject-introspection
person eponier    schedule 11.02.2017    source источник

Ответы (1)


arrow_upward
2
arrow_downward

насколько я понимаю, gobject-introspection можно использовать для создания .gir и .typelib для любой документированной библиотеки C, а не только для библиотеки на основе gobject.

На практике это не совсем так. Вы можете делать некоторые очень простые вещи, но вам придется писать GIR вручную (вместо того, чтобы просто запускать программу, которая сканирует исходный код). Единственные, о которых я знаю, это распространяемые вместе с gobject-introspection (файлы *.gir, файлы *.c существуют, чтобы избежать циклических зависимостей), и даже они, как правило, являются лишь довольно небольшим подмножеством C API.

Что касается других функций, то почти все в GObject помогает… основная идея в том, что для привязок часто требуется RTTI. Существуют такие типы, как GValue (простое поле для хранения значения + информация о типе), GClosure (для обратных вызовов), свойства и сигналы описываются с помощью GTypes, и т. д.. Если вы используете GObjects (вместо создания нового фундаментального типа), вы получаете данные о наследовании и интерфейсах во время выполнения, а странная схема построения GObject даже позволяет другим языкам создавать подклассы типов, объявленных в C.

Причина, по которой g-ir-scanner мало что может сделать с библиотеками, отличными от GObject, заключается в том, что вся эта информация отсутствует. После сканирования исходного кода в поисках аннотаций g-ir-scanner фактически загружает скомпилированный модуль и использует API GObject для получения этой информации (что делает кросс-компиляцию болезненной). Другими словами, GObject-Introspection — гораздо меньший проект, чем вы думаете… огромный процент необходимых ему данных он получает из API GObject.

person nemequ    schedule 12.02.2017
comment
Спасибо, я не знал, что g-ir-scanner использует GObject таким образом. Что касается RTTI, действительно ли это полезно для неинтерпретируемого языка? Например, он успешно используется в PyGObject, но имеет ли он смысл в скомпилированном языке? - person eponier; 14.02.2017
comment
Это имеет больше смысла, если вы используете s/interpreted/dynamicly typed/. Но ответ — да; это определенно более полезно, когда у вас нет информации о статическом типе, но в C есть много случаев, когда вы можете избежать переписывания одного и того же кода снова и снова, используя что-то вроде GValue или добавляя GType параметр. - person nemequ; 14.02.2017
comment
Не могли бы вы привести пример, иллюстрирующий ваше последнее предложение, пожалуйста? - person eponier; 15.02.2017
comment
Первое, что приходит на ум, я не знаю почему, это API, такие как подготовленные операторы для баз данных или синтаксический анализ форматов данных (например, json). Разве вы не хотели бы иметь set_int, set_uint(unsigned int value), set_double(double), set_string(char*), set_data(uint8_t*) и т. д. для каждого уровня вашего API, или вы бы предпочли просто иметь один set_value (значение GValue *)? Как насчет чего-то вроде GBinding (developer.gnome.org/gobject/stable/GBinding.html< /а>)? Если вы знакомы с языками с дженериками или шаблонами, практически в любое время, когда вы будете использовать один из них. - person nemequ; 15.02.2017