GObject: основы

[norlin]

Безотносительно статьи, я правильно понимаю, что на КДПВ котик взламывает комп, бесконтактно передавая сигналы из лапы в клавиатуру и потом передавая полученные данные через хвост куда-то ещё?

[justhabrauser]

«привязки к GLib/GTK+»: Glib != GTK

[potustoronnimv]

Glib != GTK

В таком виде да. Но GTK+ построен на системе GObject, которая является частью GLib, так же как построены на GObject GStreamer, GSettings, Pango, GIO, ATK и многие другие, более высокоуровневые системные компоненты.

[technic93]

И чем это лучше обычных плюсов?

[apro]

И чем это лучше обычных плюсов?

Насколько я понимаю, основное преимущество C (с точки зрения разработчиков gtk+), над остальными языками это ABI.
C C++ проблема даже использовать библиотеку скомпилированную одним компилятором,
из библиотеки/программы собранной другим компилятором C++. А чего уж говорить о взаимодействии с другими языками программирования.

[potustoronnimv]

Хотя бы из соображений удобства создания биндингов для более высокоуровневых языков. Кроме того, значительный пласт приложений под UNIX-системы использует фреймворк GLib/GTK+ в чистом виде.

[biseptol]

«Убъемся, напишем глючный небезопасный С++ на макросах и указателях на чистом С, лишь бы не писать на C++»

[Kobalt_x]

как там у c++ со стандартным ABI во всех компиляторах?

[biseptol]

Да лучше уж С-шные обертки экспортировать, чем этот ужас.

Сорри, у меня легкая степень PTSD, я писал плагины для GStreamer-а пару лет назад, до сих пор рябит перед глазами.

[pixelcube]

Если хочется красоты с GLib, то есть Vala.
GStreamer плагины на нем хорошо пишутся, исходного кода раза в четыре меньше.

[apro]

Да лучше уж С-шные обертки экспортировать, чем этот ужас.

А как сделать-то? Захочешь например чтобы могли наследовать объекты в других языках и вот вместо наследования C++:
struct Derive { struct Base base; };
захочешь чтобы виртуальные функции могли переопределять в других языках и вместо virtual у тебя указатели на функции, вместо неявного this передается
явно указатель на структуру, и сколько c++ от c++ останется?

[biseptol]

А зачем это все? Может в архитектуре что-нибудь исправить, если приходится протаскивать наследование, да еще и с virtual методами в другие языки?

[Lsh]

А что вы скажете про Vala? Насколько оно живое и насколько стабильное? Можно ли на Vala написать что-то, что потом будет использоваться в других языках через биндинги?

[potustoronnimv]

Vala вполне живой и развитый проект, очень удобный и простой C#-подобный язык, но компилируется в нативный код. Изначально конвертировался препроцессором в си-код, после чего компилировался любым си-компилятором. Вообще, по хорошему, Vala — просто обёртка вокруг GObject, эдакий синтаксический сахар.

[bamovetz]

Самый большой грех основателей open-source и в частности создателей Линукс в том что они, являясь ярыми сишниками, проигнорировали весь труд Страуструпа и компании. Они даже готово были переизобрести Си с классами вместо использования С++. В GLibs очень яркий пример — гигантский проект, реализация GUI — идеально ложится на ООП в С++. Но нет мы же пишем только на Си. Придумаем свои классы на неотлаживаемых макросах и будем гордиться. А потом когда уже макросы начнут доставать сделаем свой язык Vala. Но С++ использовать религия не позволяет.

[potustoronnimv]

Изначально, возможно, их можно было упрекнуть в этом. На данный момент, GLib и набор библиотек, простроенных на ней, являются сишным ядром, а разработка может вестись на более высокоуровневых языках, в том числе и C++ (gtkmm и glibmm — биндинги к C++).

Что касается Vala, тут вы сравниваете совершенно разнородные сущности. У Vala вполне конкретная ниша — прикладные десктопные приложения, в первую очередь для GNOME и GTK-based окружений. У Vala очень простой и дружелюбный синтаксис, обширная стандартная библиотека, делающая построение десктопных приложений простым и приятным процессом. Вне этой ниши использовать Vala большого смысла нет, в общем-то. Это не конкурент C++, скорее, его можно сравнивать со Swift — язык конкретный платформы и фреймворков.