В чем смысл GObject?

[Lion-Simba]

Задумал я на днях написать одну весчь... а именно плагин для gstreamer'а.
Давай читать документацию и вот наткнулся на GObject...

Как я понял, GObject - это часть библиотеки GLib, с использованием которой написан Gnome (GTK?). Суть этой библиотеки в том, что она позволяет на чистом С (без плюсов) создавать объектно-ориентированные программы.

gstreamer также использует эту концепцию.

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

Собственно вопрос к тем, кто сталкивался и(или) программирует с использованием GObject и Glib:
чем она так хороша? чем она принципиально лучше С++? и почему gstreamer взял за основу именно эту концепцию?

Вот как-то это у меня не совсем в голове укладывается во времена не то чтобы С++, а уже Java, C#'ов, Python'ов...

[pretorean]

я думаю что так сложилось исторически

Вот как-то это у меня не совсем в голове укладывается во времена не то чтобы С++, а уже Java, C#'ов, Python'ов...

это вы погорячились ... я думаю эпоху С будем считать законченой когда ядро на С# или чемто подобном перепишут

[Thread]

уже, кстати, есть прецедент - SharpOS

[pretorean]

уже, кстати, есть прецедент - SharpOS

и уже есть опыт его промышленной эксплуатации ?

[Denis Konstantinov]

Задумал я на днях написать одну весчь... а именно плагин для gstreamer'а.
Давай читать документацию и вот наткнулся на GObject...

Как я понял, GObject - это часть библиотеки GLib, с использованием которой написан Gnome (GTK?). Суть этой библиотеки в том, что она позволяет на чистом С (без плюсов) создавать объектно-ориентированные программы.

gstreamer также использует эту концепцию.

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

Собственно вопрос к тем, кто сталкивался и(или) программирует с использованием GObject и Glib:
чем она так хороша? чем она принципиально лучше С++? и почему gstreamer взял за основу именно эту концепцию?

Вот как-то это у меня не совсем в голове укладывается во времена не то чтобы С++, а уже Java, C#'ов, Python'ов...

http://linfoline.homedns.org/API/gobject/index.html
http://en.wikipedia.org/wiki/GObject
http://linfoline.homedns.org/gtk/c24.html

по существу это специальные "хаки" которые позволяют писать ОО код на С, следуя лишь определённым правилам при описании структур как "классов".
Плюсом считается простота создания обёрток в другие языки (C++ Python Perl и т.д.) размер получаемого кода и скорость работы. Минусы, т.к. Си язык можно сказать низкого уровня, в том плане, что нужно самому следить сколько памяти выделить и когда её освободить, это приводит к тому что нужно больше обращать внимания на код который пишешь. Т.е. сложнее для новичков.

[Lion-Simba]

Вот как-то это у меня не совсем в голове укладывается во времена не то чтобы С++, а уже Java, C#'ов, Python'ов...

это вы погорячились ... я думаю эпоху С будем считать законченой когда ядро на С# или чемто подобном перепишут

Речь идет не о ядре (где вставки на assembler очень даже используется), а о прикладных приложениях... Хотя может быть это и оправдано в gstreamer, т.к. он обязан быть быстрым. Хотя с другой стороны... ну неужели runtime регистрация типов будет работать быстрее скомпилированных типов С++?

Спасибо Denis Konstantinov за ссылки, буду изучать.
За памятью и в C++ следить надо... Но согласен, что внимания этот код требует действительно больше.

Мне же главным кажется:

я думаю что так сложилось исторически

Какбы это не выросло в проблему. Ибо... зачем новоиспеченному программисту изучать какой-то GObject, если он с тем же успехом может сделать то же самое в более удобном ему С++? Не приведет ли это к уменьшению притока программистов к разработке подобных приложений и GNOME в частности? И, следовательно, не ставят ли этим разработчики Gnome себя (и свой проект) в тупик? Как вы думаете?

Плюсом считается простота создания обёрток в другие языки (C++ Python Perl и т.д.)

Возможно... однако gstreamer С++ bindings до сих пор under development... Грустно.

[cranky]

Какбы это не выросло в проблему. Ибо... зачем новоиспеченному программисту изучать какой-то GObject, если он с тем же успехом может сделать то же самое в более удобном ему С++? Не приведет ли это к уменьшению притока программистов к разработке подобных приложений и GNOME в частности? И, следовательно, не ставят ли этим разработчики Gnome себя (и свой проект) в тупик? Как вы думаете?

К счастью, программистов, которые выбирают ЯП в зависимости от решаемой задачи больше чем тех, кто использует то, что ему удобней. А уж осилить небольшую надстройку, думаю сможет любой желающий.

[Lion-Simba]

которые выбирают ЯП в зависимости от решаемой задачи

Угу. А не кажется ли вам, что разработчики Gnome и gstreamer в данном случае поступили наоборот?
Это я о том, что создавать ОО программы гораздо проще на языках, специально для этого предназначенных.

Понятно, что теперь если я хочу написать плагин к gstreamer ("задача"), мне придется изучать GObject (типа "ЯП"), но изначально для создания ОО фреймворка ("задача") был выбран НЕ ОО язык. Вот я о чем.

[cranky]

которые выбирают ЯП в зависимости от решаемой задачи

Угу. А не кажется ли вам, что разработчики Gnome и gstreamer в данном случае поступили наоборот?
Это я о том, что создавать ОО программы гораздо проще на языках, специально для этого предназначенных.

Понятно, что теперь если я хочу написать плагин к gstreamer ("задача"), мне придется изучать GObject (типа "ЯП"), но изначально для создания ОО фреймворка ("задача") был выбран НЕ ОО язык. Вот я о чем.

Я так и не понял сути проблемы.. Разве кто-то запрещает использовать объектный метод в неОО языках? А уж удобней писать на ОО или ФП - это личное дело каждого. Мне вот плюсы совсем не нравятся, лучше уж Objective C (а ещё лучше - хаскель ), но я же не жалуюсь, что кеды на богомерзких плюсах написаны.

[Lion-Simba]

[Я так и не понял сути проблемы..

Проблемы с моей стороны нет (если ты об этом).
Я просто выражаю свои мысли по поводу нелогичности выбора разработчиков. И хочу узнать мысли форумчан по этому поводу.

Разве кто-то запрещает использовать объектный метод в неОО языках?

Никто не запрещает. Они это и делают. Вопрос, верно ли был выбран язык под конкретную задачу (написание ОО фреймворка)...

А уж удобней писать на ОО или ФП - это личное дело каждого.

Это да.
Однако в случае с gstreamer нас прямо-таки вынуждают писать на ОО в неОО языке. Сие есть правильно?

[zlos]

Достоинство ООП на C - оно компилируется везде. Известно же, что C++ компиляторы на некоторые платформы с "заскоками" и могут генерировать некорректный код или вообще не воспринимать некоторые конструкции. Для переносимости следует использовать скорее C-с-классами, своеобразное подмножество C++. Но тут уже совсем недалеко и до C. Что и сделано в GLib.

[Yurror]

Ого? кому известно? давайте не будем голословными. линки в студию.

[Thread]

Достоинство ООП на C - оно компилируется везде. Известно же, что C++ компиляторы на некоторые платформы с "заскоками" и могут генерировать некорректный код или вообще не воспринимать некоторые конструкции. Для переносимости следует использовать скорее C-с-классами, своеобразное подмножество C++. Но тут уже совсем недалеко и до C. Что и сделано в GLib.

Так было лет 7-8 назад, а сейчас большинство компиляторов реализуют практически весь стандарт C++.

[asashnov]

А что за плагинчик задумал написать? Просто я сейчас тоже курю эту траву- vtx формат хочу прикрутить.

Сам плагин можешь писать на чем угодно! главное потом сделать gobject и встроить его в систему.
Вот они и плюсы- если бы gstreamer был на Java, пришлось бы все на одном языке писать, а тут меж-языковая совместимость.

[Lion-Simba]

А что за плагинчик задумал написать?

Да сущие пустяки, право - videosink с выходом на Compiz VideoPlugin, дабы можно было видео нормально смотреть через гстример на ненормальных видеокартах от ATI А то обидно как-то.. mplayer и всё.

Разобрался как работает патч для mplayer и Compiz VideoPlugin. Взял за основу ximagesink, разобралая и в нем. Провел первичное изменение кода. Пока что все это дело вываливается в segfault. Порывов разрабатывать дальше пока нет. Но думаю будут, если раньше не выйдут нормальные драйвера для моей видеокарты.

Но это разговор для отдельной темы.