Gnome roadmap: планы на версии 2.20 и 2.22

> Как - же тогда компилятор C++ умудряется пережовывать обыкновенный C если у C++ другой синтаксис.

Вам предоставить код на С, на котором плюсовый компилятор закашляется - или Вы поверите, что такой код есть?

> С каждым релизом - все менее жалкое!

В каком релизе догоните?

> "C++ is a general purpose programming language with a bias towards systems programming"

А где это у нас ядра на C++?

> где тут про "C extention"?

Читаем далее:

Thus, C++ is as much a superset of ANSI C as ANSI C is a superset of K&R C and much as ISO C++ is a superset of C++ as it existed in 1985.

GNOME (n) --> MacOSX (m) / m,n -> oo

> Тем что в некоторых языках она используется просто и приятно, а в других через одно место.

не аргумент. есть тот же gob - если так напрягает использовать напрямую.

> И ни в одном callbackе, вы ни используете ни одной функции Gtk? Не верю (C)

да, тут малость погорячился.

> А где это у нас ядра на C++?

винда? хотя и не уверен.

> Когда я читаю такие посты, у меня создаётся впечатление, что гном юзают одни имбецилы. Ибо по числу самых дебильных, хамских и бессодержательных постов гномосеки безусловно лидеры! ;)

Ды Вы что! Как Гном является лишь бледным подобием КДЕ, так и гномеры являются лишь слабым подражанием кедофилам.

> где тут про "C extention"?

Взять синтаксис C и добавить новых фичь, я называю это расширить C.

Я иммел ввиду что если вам нужен C и ОО, возьмите C++ и не изобритайте велосипедов.

2svu:

> Вам предоставить код на С, на котором плюсовый компилятор закашляется - или Вы поверите, что такой код есть?

Я в курсе, не бери меня за идиота. Но это ничего не меняет, т.к. в C++ нет фундаментальных синтаксических различий это не совсем новый язык. Так говорит даже сам Страуструп.

> У меня тут это довели до логического конца - функциональное программирование на VBA. А что, парадигма ведь к языку не привязана, так?

ну, некоторые вообще марки собирают.

> винда? хотя и не уверен.

Возможно, BeOS

> Я иммел ввиду что если вам нужен C и ОО, возьмите C++ и не изобритайте велосипедов.

а также поимейте гимор с линковкой с не c++ кодом. да ну нафиг.

> есть тот же gob - если так напрягает использовать напрямую.

А это уже костыль. К тому - же все равно если вы делаете биндинг к языку имеющему нативный ОО, получится левая сушность. Хотя не уверен что с плюсами тут легче.

> винда? хотя и не уверен.

По моему нет, но была BeOS.

> Я в курсе, не бери меня за идиота.

Ээээ Насколько я знаю, в русском языке "не держи меня за идиота"? Или я что-то пропустил?

> это не совсем новый язык.

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

> Так говорит даже сам Страуструп.

А еще этот глубоко уважаемый (практически без шуток) специалист ругался на то, что развитие С (С99) идет не в ту сторону, куда надо плюсам. И есть мнение, что расхождение со временем будет углубляться.

> А это уже костыль. К тому - же все равно если вы делаете биндинг к языку имеющему нативный ОО, получится левая сушность. Хотя не уверен что с плюсами тут легче.

yacс тоже костыль? xml+xslt для генерации разных форматов док из одного исходника - тоже костыли? путь джедая - все делать руками?

> а также поимейте гимор с линковкой с не c++ кодом. да ну нафиг.

С кодом на каком языке? Я линьковал с C, Fortran и OCaml. Никаких особых проблем замечено не было.

> строгим подмножеством

строгим - нет, а фактически - практически да.

> Я иммел ввиду что если вам нужен C и ОО

А если мне нужен асм и реляционная алгебра? Зачем ставить бессмысленные задачи по нахождению компромисса и потом мучительно его искать, убивая все хорошее, что есть в частных решениях _отдельных_ задач?

> фактически - практически

Под это можно подвести что угодно.

> Насколько я знаю, в русском языке "не держи меня за идиота"?

Извини, сказиваються 6 лет жизни за границей ;-)

> что плюсы являются строгим подмножеством и расширением С.

Я и не утверждал что C++ это _строгое_ подмножество C. Но это не отрицает факта, что на практике это так.

> И есть мнение, что расхождение со временем будет углубляться.

Я не спорю, но мы говорим про сейчас.

> убивая все хорошее, что есть в частных решениях _отдельных_ задач?

Это не отменяет факта что ГУЙ удобнее писать на ОО языках.

Ну так Страсутруп считает, скажи ему что он не прав.

Согласен. При чем тут С?

> Извини, сказиваються 6 лет жизни за границей ;-)

А у меня 7 лет не сказываются, думаете?;)

>Гном рулит, КДЕ и ананимусы сасут. Ну, кроме того, правильного ананимуса - грамотного, с женой и чеширским котом.

По экспрессивности и афористичности выражения ты почти догнал Гика.

>C++ обратно совместим с C, поэтому он не совсем самостоятельный.

предлагаю тебе сначала подучиться, чтобы не делать таких вот ляпов

>А *формально* - это практически расширение C.

*формально* ECMAScript - расширение Java. да? Ну а чо - синтаксис-то похож

>Это не отменяет факта что ГУЙ удобнее писать на ОО языках.

ога. На python + pygtk например

>По экспрессивности и афористичности выражения ты почти догнал Гика.

вот и слава пришла :)

> Согласен. При чем тут С?

Gtk и Qt предназначены для написания GUI.

В C нет ОО, а в C++ есть.

Gtk написана на C, Qt написана на C++.

Я утверждаю что разработчики Qt выбрали более адекватный язык для данной задачи ( написание GUI ).

>В C нет ОО, а в C++ есть.

в С есть ОО. сурприз, да?

>Я утверждаю что разработчики Qt выбрали более адекватный язык для данной задачи ( написание GUI ).

можешь утверждать всё что угодно - на реальность это не влияет никак

> предлагаю тебе сначала подучиться, чтобы не делать таких вот ляпов

Я уже разжевал выше что я имел ввиду.

> *формально* ECMAScript - расширение Java. да? Ну а чо - синтаксис-то похож

C++ не просто похож на C, а я бы сказал очень, ну очень похож.

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

> ога. На python + pygtk например

Да хоть на Лиспе, Сшная суть Gtk все равно вылезает.

> в С есть ОО. сурприз, да?

Где, покажи?! ;-)

> можешь утверждать всё что угодно

Но в отличии от тебя, я ещё и аргументирую.

>>По экспрессивности и афористичности выражения ты почти догнал Гика.

>вот и слава пришла :)

...Несмотря на всю скромность :-)

конвульсии в чистом виде. так трудно смириться? к сожалению, это реальный мир. фтопку гнома.

>Я уже разжевал выше что я имел ввиду.

от того что ты считаешь C подмножеством C++ он таковым не станет

>C++ не просто похож на C, а я бы сказал очень, ну очень похож.

жаба тоже на C++ похожа. Очень. C++ - подмножество жабы?

>К тому же тебе привели выше высказывание Страуструпа на эту тему. Так что включи мозг и не делай из себя идиота.

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

>Да хоть на Лиспе, Сшная суть Gtk все равно вылезает.

а в лиспе тоже нет ооп? =)

>Где, покажи?! ;-)

А ты знаешь, что такое ООП? Суда я по всему - ты уверен, что это ключевое слово "class"

>Но в отличии от тебя, я ещё и аргументирую.

вопли "я утверждаю" на аргумент не тянут

>Новая доска позора для разработчиков этой дряни?

а что вы так злобствуете-то?

> Gtk и Qt предназначены для написания GUI.

Ага. И могут использоваться более высокоуровневыми языками. И вот там можно получить нормальный ОО на уровне языка.

> В C нет ОО, а в C++ есть.

Принципиальное дополнение: "на уровне языка". Если убрать требование иметь ОО на уровне языка, в С ОО есть. Практически любая приличная библиотека на С - в той или иной мере ОО.

Сходный по сути вопрос: есть ли в Java Hashtable. На уровне языка (как во многих других скриптовых языках) - нет. В стандартной библиотеке - есть. В результате, для программиста он - есть. Это главное. Так и в С для программиста ОО есть. Но не на уровне языка. Это безусловно делает соотв. конструкции внешне не столь симпатичными, как в С++. Но зато упрощает язык (сложность синтакса плюсов по сравнению с голым С просто демоническая).

> Я утверждаю что разработчики Qt выбрали более адекватный язык для данной задачи ( написание GUI ).

Ну, что и почему я утверждаю, давно уже всему ЛОРу известно;)

>> А где это у нас ядра на C++?

> винда? хотя и не уверен.

нет, винда написана на С.
И WINAPI тоже.
Есть расширения,GUI на СРР - MFC, на c#- GDI+.

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

* до висты по крайней мере

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

А что у нас нонче не быдлоязык, кстати? Brainfuck?

(Язык с валящими программу функциями типа gets и изучаемый в вузах - явно быдлоязык)

Различия в скорости и потреблении памяти между QT2-QT3 (KDE) заметны на глаз, в лучшую сторону. В QT4 заявлено ещё большее увеличение производительности и кода писать меньше нужно.

Различия в производительности между GTK(gnome-1.4) и GTK2(gnome2,плейлист XMMS vs Audacious) тоже заметны на глаз, в худшую сторону, что мне показалось странным (я ожидал обратного)

Кто-то некоторое время назад высказывался мол эти тормоза в GTK2 оправданы, т.к. добавляется функциональность и это есть прогресс, а то, что QT от версии к версии становится быстрее, ничуть не уступая по функциональности (если не превосходя) + меньшие затраты (строки кода) - это не труЪ...

Скорость и простота кода, наличие хороших пособий и пр. - это сильные стороны QT. Назовите такие у GTK2, пожалуйста, и без аргументов вроде "а я купил себе мощное железо и теперь GTK не тормозит, а значит ваш QT - кака (потому, что не LGPL)".

> от того что ты считаешь C подмножеством C++ он таковым не станет

Если ты не адекватно смотриш на мир, он от этого не поменяется ;-)

> жаба тоже на C++ похожа. Очень. C++ - подмножество жабы?

У C++ и Java есть фундаментальные различия в синтаксисе, у С и C++ их нет.

> Страуструпу конечно хотелось бы, чтобы его быдлоязычок обзавелся аристократическими корнями,

Извини но Спрауструп является для меня более авторитетной фигурой чем ты, особенно что касается C++ ;-)

> а в лиспе тоже нет ооп? =)

Я в курсе, это был просто пример

> А ты знаешь, что такое ООП?

Да

> Суда я по всему - ты уверен, что это ключевое слово "class"

Нет

Использовать ОО и в Brainfuck можно, только зачем себя мучить?

> вопли "я утверждаю" на аргумент не тянут

Читать умеем? Если да, перичитай тот пост, если нет, марш в школу.

В целом хотелось бы чтобы гном не загнулся, все-таки.

Хотя лично мне он не нравится.

> И вот там можно получить нормальный ОО на уровне языка.

Это будет уже не биндинг 1 к 1, и следовательно уже несколько другая библиотека.

> Принципиальное дополнение: "на уровне языка"

Если вы собрались использовать ОО логичнее использовать язык поддерживающий ОО "на уровне языка".

> есть ли в Java Hashtable.

Это не совсем коррекное сравнение. Реализован ли Hashtable на уровне языка или в стандартной библиотеке значения не имеет, а вот ОО на уровне библиотеки вы нормально не реализуете. Это фишка языка.

> Но зато упрощает язык

Тут главное сильно не наупрощать. ;-) Согласитесь что в C не хватает очень многих вкусностей.

> Ну, что и почему я утверждаю, давно уже всему ЛОРу известно;)

Ваше личное мнение для меня священно и я не смею к нему прикасаться. ;-)

> Это будет уже не биндинг 1 к 1, и следовательно уже несколько другая библиотека.

Почему? Gobject - вполне себе ОО framework. И неплохо мапится в ОО модели большинства скриптовых языков. То, что в С выглядит немного тяжеловесно (но тем не менее ОО!) из-за отсутствия языковой поддержки - становится естественным в тру ОО языках. Кстати, при несовпадении объектных моделей любой байндинг будет не 1 к 1. В этом смысле ОО плюсов/Qt не лучше и не хуже, чем ОО GObject.

> Если вы собрались использовать ОО логичнее использовать язык поддерживающий ОО "на уровне языка".

Логичнее - да. Но необязательно. И, если уж приспичит, я возьму язык, где ОО реализовано лучше. Например, где есть нормальная полноценная рефлексия, _отсутствует_ (!= "можно не использовать") понятие "указатель на кусок памяти" и пр. и пр.

> реализован ли Hashtable на уровне языка или в стандартной библиотеке значения не имеет

В конечном итоге, борьба идет за хороший понятный текст программы. В этом смысле встроенный в язык hashtable (а лучше - мало отличимый от массивов) весьма удобен.

> Согласитесь что в C не хватает очень многих вкусностей.

+100. Просто не надо было вводить в плюсы священную корову совместимости с С. Тем более что эту корову медленно таки убивают (просто потому что корова отказывается стоять на месте и идет в другую сторону).

> Почему? Gobject - вполне себе ОО framework

Впринципе я с вами согласен, но

> в С выглядит немного тяжеловесно

Я просто не понимаю зачем делать библиотеку _не удобной_ в _родном языке_. Почему сразу не написать её на более высокоуровневом.

> Но необязательно.

Естественно, вопрос зачем?

> И, если уж приспичит, я возьму язык, где ОО реализовано лучше. Например, где есть нормальная полноценная рефлексия, _отсутствует_ (!= "можно не использовать") понятие "указатель на кусок памяти" и пр. и пр.

+100 Но спор был Qt vs. Gtk+ и следовательно C vs. C++

> В этом смысле встроенный в язык hashtable (а лучше - мало отличимый от массивов) весьма удобен.

Ну если в языке есть перегрузка операторов то этого можно добиться на уровне библиотеки, нет?

> Просто не надо было вводить в плюсы священную корову совместимости с С.

+1000

> Почему сразу не написать её на более высокоуровневом.

Потому что С исторически используется как "наибольший общий делитель" в унихе. Кстати, GObject не то чтоб неудобен. Он просто слегка многословен, я б сказал.

> Ну если в языке есть перегрузка операторов то этого можно добиться на уровне библиотеки, нет?

Да, но перегрузка операторов чревата другими проблемами. Честно скажу, я рад, что в жабке ее нет. Я вообще не очень напрягаюсь на многословность. Я больше не люблю неявности и умолчания;)

>> Просто не надо было вводить в плюсы священную корову совместимости с С.

> +1000

На этом месте можно считать нас в среднем договорившимися;)

> С исторически используется как "наибольший общий делитель"

В современных языках есть на много больше обших фишек чем в C. Традиции это хорошо, но надо-же когда-то их менять. ;-)

> перегрузка операторов чревата другими проблемами. Эх, но больно удобная, сволочь!

> На этом месте можно считать нас в среднем договорившимися;)

Ну вот и славненко! Пошли спать. ;-)

Переход QT2 - QT3 был намного более эволюционным, чем переход gtk - gtk2. Фактически, gtk2 это совсем другой тулкит. А вот с после этого gtk2 действительно становился все шустрее и шустрее - примерно так же, как qt.