Скажите мне, что я не одинок

стыдно, но не осилил.

Чтобы не использовать Qt? :)

Ты не одинок, сын мой. Бог любит тебя.

Ну и что? С++ же был уже, когда инфраструктура Gtk+ проектировалась.

use Qt4 luke!

Чтобы потом создать Vala, очевидно же.

Vala - это что-то вроде MOC в Qt, но круче. И на фоне С++ смотрится костылем. Непонятно все-таки - зачем?!

Вот, знающие люди, объясните мне: почему Gtk накрутили поверх C испытав при этом неимоверное количество батхарда? Почему не использовать С++? Я понимаю если бы выбор лежал между C++ и Haskell, но, что C, что C++ одного поля ягода...

GObject - священная вещь. Она слишком божественна и слишком совершенна для простых программистов. Ты должен стремиться к просветлению, самосовершенствованию и полнейшей душевной гармонии, сын мой, ибо такова воля Творца.

Потому что C.

А где же тролли с криками, что GObject Ъ, а всё остальное не нужно? :( Вообще, конечно, хотелось бы послушать, зачем оно надо было.

Чтобы сделать ООП в сях, не?

Столько времени и сил только на это убили?

Ну, так были уже плюсы, в чём был смысл C + GObject лучше, чем C++?

что C, что C++ одного поля ягода

Гм. Гм гм гм.

он в том плане, что нахрена прикручивать к си классы если они уже есть в с++

> Гм. Гм гм гм.

Ну.... если сравнивать с Lisp, Haskell, Scala и др, то с этой точки зрения разница между C и C++ и вовсе не заметна. :P

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

Ждем криков ниасиляторов по поводу ООП в ядре. А то там мужики тоже не в курсе про Си++.

> на языках, которые поддерживают ООП?

Ну написал ты на одном ООП-языке кучу классов, на другом кучу классов, а потом попробуй склеить типа. Я так понял, что для этого и был придуман GObject (а еще типа единая организация сигналов и подобной фигни для ГУЯ). В документации и википедии же все прекрасно написано, не?

А вообще язык Vala мне очень и очень понравился, современный такой и после его фишек глядя на C++ хочется идти в туалет как минимум мыть руки. Хотя и все равно синтаксическая совместимость с Си, хотелось бы, чтоб отмерла и не было стыдно за такой «Hello, world» в 2010м году.

Вот пожалуй единственный здравый камент в этой теме! Молодец!

В ядре не используется даже 5% от того, что есть в GObject. Слабо виртуальность реализовать на Си? Вот. А в GObject это сделано!

В ядре вся мощь Gobj и не нужна. Не надо вообще путать системное программирование с прикладным.

>Почему не писать просто на языках, которые поддерживают ООП?

Спроси у Линуса и других писателей ядра :)

> Слабо виртуальность реализовать на Си?

Виртуальные методы? Нет, не слабо.

Вот. А в GObject это сделано!

Я в курсе. А еще это сделано и в CPython.

В ядре тоже используется и наследование, и виртуальные методы, и прочее ООП. Правда через гораздо большее количество магических макросов нежели в GObject.

Причем тут ядро? Суть в применимости ООП в _ПРИКЛАДНОМ_ программировании.

Ты не одинок. Я все понимаю. Мы все проходим через жизненные трудности.

> Ну написал ты на одном ООП-языке кучу классов, на другом кучу классов, а потом попробуй склеить типа. Я так понял, что для этого и был придуман GObject

он был придуман для GTK, а пресловутые биндинги для других языков - побочный эффект, который никому не нужен

вообще язык Vala мне очень и очень понравился, современный такой

тупо содрали с C#

и после его фишек глядя на C++ хочется идти в туалет как минимум мыть руки

недо-C# реализованный в виде транслятора в С... - лучше уж С++

C# неудобно юзать на платформах отличных от x86. А С++ в проекте на С юзать - плодить лишние проблемы.

пусть растут все цве^Wсорняки

а Objective C, например?

когда работал например с glib'ом, не мог не удержаться и не сделать плюсовую морду для GSList. стало как-то это... удобнее, чтоли.

> Почему не писать просто на языках, которые поддерживают ООП?

Ага, вот ты и оценил всю прелесть и элегантность GTK. Не трать больше на него время, есть же Qt.

> а Objective C, например?

Не знаю, когда я попробовал его изучить мой мозг был разломан на мелкие осколки. Очень странный язык, в котором, видимо, было слишком много хаков. Нет, Vala куда приятнее и понятнее любому джава- сишарп- и сиплюсплюс-программисту.

> он был придуман для GTK, а пресловутые биндинги для других языков - побочный эффект, который никому не нужен

Не знаю, но сдается мне что с GObject'ом гораздо легче общаться между питоном и си, помню на прошедшей конференции по питону в Киеве два чувака показывали взаимодействие питона с си (ну там для задачи какой-то более прикладной) — все были тупо в ужасе от красноглазия, происходящего на сцене и иногда хотелось даже выкрикнуть «Патрег Бох» и удалиться на кофе.

> вообще язык Vala мне очень и очень понравился, современный такой

тупо содрали с C#

Ну, тупо-не тупо, но как раз ЯП, подобного C# но не C# в мире (имхо) и не хватало. Были надежды на D и прочее, но здесь еще ты получаешь ЯП, в котором есть все сишные библиотеки и плюс ты пишешь над ними легковесную ООП-обертку. Тоесть теперь, когда мне нужно будет написать нечто быстрое — я буду это делать на Vala и использовать все библиотеки сишные какие захочу. Правда есть подозрение, что дебаг этого дела — не так приятен (я так понял дебажить надо сишный код), хотя с другой стороны Vala (по идее) генерирует очень понятный сишный код и в документации по Vala прям сразу же и описывается каким получится сишный код.

недо-C# реализованный в виде транслятора в С... - лучше уж С++

В том-то и дело что не лучше, а гораздо-гораздо хуже. C++ просто слишком сложен и стар. А транслятор в Си там (как я уже писал) делается прозрачным для того, чтоб потом из Си с легкостью использовать код классов из Vala (да да, через тот же gobject). А это — скорее фича, чем баг. Тоесть ты тот же ГИМП можешь допиливать на Vala и твой код будут использовать вполне хорошо.

В общем, окончательного решения у меня еще нету, хочу почитать код какой-нибудь shotwell, вникнуть в него и уж тогда что-либо для себя решить.

Ну, например, в коде на Си/GObject недавно видел такую штуку, что в описании SomeObjectClass виртуальных методов добавляют еще reserved поля. Т.е. потом можно расширить количество виртуальных методов, не портя бинарной совместимости для классов, которые будут наследоваться от него. И при программировании на Си программист об этом задумывается.

А задумались ли бы об этом C++/Vala программисты? Уверен, что мало кто из них знает, как все устроено и чем они платят за использование конструкций языка.

Огромную роль в выборе C для Gtk+ также играет поддержка кучи биндингов на зоопарк языков. Сравните сколько языков поддерживает Qt, и сколько Gtk. Хотя, конечно, польза сомнительна.

Зато теперь GTK можно использовать из кучи языков в том числе и из языков в которых ООП нет. А в Qt на каком языке его не вызывай получается C++.

Тема обсуждалась не раз. GObject позволяет получать полный RTTI, интроспекцию, причем делать это кросскомпиляторно. Тоесть на основе существующего экземляра класса GObject можно на лету сгенерировать обьект JavaScript или Python, чтобы потом его использовать в скрипте. Или например сериализировать сложный класс. Плюс встроеные счетчики ссылок в каждом обьекте, которые можно использовать уже в С, но особенно хорошо работает в байндингах, где о этом не нужно париться. У С++ и с тем и с другим есть проблемки.

У С++ и с тем и с другим есть проблемки.

Full RTTI и кросскомпиляторность. Первое можно сделать, но такими же методами, как это делается в GObject, второе увы нет.

Не гони. Есть glibmm. Нельзя было хотя-бы по википедии полазить. Кстати относительно вопроса

Почему не писать просто на языках, которые поддерживают ООП?

Можно и нужно. Glibmm/Gtkmm намного удобнее и приятнее, чем фак-мой-мозг на С. А разработчикам библиотек на С спасибо, что они «настолько суровы», что пишут код на С и создали GObject. Теперь можно радоваться байндингам

>тупо

тупо

тупо

тупо

Тупо в тупо треде тупо повышенная тупо концентрация тупо.

>что C, что C++ одного поля ягода...

Омг, удали это быстрее пока никто не увидел!

GObject Ъ, а всё остальное не нужно

>Ну, так были уже плюсы, в чём был смысл C + GObject лучше, чем C++?

В том, что объектная система GObject получилась местами посильней, чем стандартная плюсатая

> Огромную роль в выборе C для Gtk+ также играет поддержка кучи биндингов на зоопарк языков. Сравните сколько языков поддерживает Qt, и сколько Gtk.

Qt - это не чистый С++, у того же FLTK есть также куча биндингов - для CL, Haskell, Python, Ruby, Lua и пр.

> В том, что объектная система GObject получилась местами посильней, чем стандартная плюсатая

плюсатая расчитана на скорость выполнения, а не на «силу»

>Слабо виртуальность реализовать на Си?

Да легко. Затертый до дыр www.planetpdf.com/codecuts/pdfs/ooc.pdf например. И ещё COS есть, немного из другой оперы, но тоже для С

>когда работал например с glib'ом, не мог не удержаться и не сделать плюсовую морду для GSList

Открой для себя glibmm

> Да легко.

в теории, на практике таким пользоваться уже не так приятно

>на практике таким пользоваться уже не так приятно

Ну, мне например понравилось :)

> Ну, мне например понравилось :)

и сейчас пользуетесь?