Pull to refresh

Comments 16

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

Glib != GTK

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

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

Хотя бы из соображений удобства создания биндингов для более высокоуровневых языков. Кроме того, значительный пласт приложений под UNIX-системы использует фреймворк GLib/GTK+ в чистом виде.
«Убъемся, напишем глючный небезопасный С++ на макросах и указателях на чистом С, лишь бы не писать на C++»
как там у c++ со стандартным ABI во всех компиляторах?
Да лучше уж С-шные обертки экспортировать, чем этот ужас.

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

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

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

А что вы скажете про Vala? Насколько оно живое и насколько стабильное? Можно ли на Vala написать что-то, что потом будет использоваться в других языках через биндинги?
Vala вполне живой и развитый проект, очень удобный и простой C#-подобный язык, но компилируется в нативный код. Изначально конвертировался препроцессором в си-код, после чего компилировался любым си-компилятором. Вообще, по хорошему, Vala — просто обёртка вокруг GObject, эдакий синтаксический сахар.
Самый большой грех основателей open-source и в частности создателей Линукс в том что они, являясь ярыми сишниками, проигнорировали весь труд Страуструпа и компании. Они даже готово были переизобрести Си с классами вместо использования С++. В GLibs очень яркий пример — гигантский проект, реализация GUI — идеально ложится на ООП в С++. Но нет мы же пишем только на Си. Придумаем свои классы на неотлаживаемых макросах и будем гордиться. А потом когда уже макросы начнут доставать сделаем свой язык Vala. Но С++ использовать религия не позволяет.
Изначально, возможно, их можно было упрекнуть в этом. На данный момент, GLib и набор библиотек, простроенных на ней, являются сишным ядром, а разработка может вестись на более высокоуровневых языках, в том числе и C++ (gtkmm и glibmm — биндинги к C++).

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

Articles