Релиз KDE 4.0 отложен до января

http://mail.gnome.org/archives/gnome-announce-list/2007-November/msg00066.html

Если это чейнджлог, то я - троллейбус. :)

> Насчёт DEBUG - угадайте, сколько раз это слово встречается в исходниках ядра? И вообще, посмотрите хотя бы, что требуется тому же Qt для работы - libpng, libjpeg, libxrandr... На чём там они написаны - на C++?.. И DEBUG в их исходниках тоже отсутствует?.. ;) geek вам правильно посоветовал - поучите, лучше, матчасть.

Дык, перепиши ::))

> Дык, перепиши ::))

Извините, я не склонен к извращениям... ;)

>Если вы пока ещё не понимаете минусов объектно-ориентированного подхода в целом

слушай, зачем тогда гномеры и пр. изобретают ОО-кодогенераторы?

>и C++, как средства программирования, в частности

да, многие его не осилили

>то это ещё не повод говорить, что C проигрывает. ;)

повод - это вывод от появления на свет очередного костыля вроде vala

>На чём там они написаны - на C++?.. И DEBUG в их исходниках тоже отсутствует?.. ;)

стандартные библиотеки экспортируют наружу функции по cdecl-спецификации, внутри написаны они могут быть на _чем угодно_ (чей компилятор генерирует родной бинарный код)

>Извините, я не склонен к извращениям... ;)

А зачем тогда сопли жевать??!! и показывать свою пассивность.. ::))

Troll detected.

> слушай, зачем тогда гномеры и пр. изобретают ОО-кодогенераторы?

Понятия не имею. :) Меня вполне устраивает процедурно-структурный подход и работа с объектами, как в Glib/GTK+.

> да, многие его не осилили

Значит, C осилить легко, а C++ - сложно, правильно я понял? Тогда в чём преимущество C++? ;) Я почему-то думал, что вы нам об удобстве рассказываете... ;)

> повод - это вывод от появления на свет очередного костыля вроде vala

Открою секрет - не все программисты на C пользуются vala. :))

> стандартные библиотеки экспортируют наружу функции по cdecl-спецификации, внутри написаны они могут быть на _чем угодно_ (чей компилятор генерирует родной бинарный код)

Да что вы говорите! А производительность тоже может быть какой угодно? ;)

>Troll detected.

Кто здесь "troll" это надо ещё разобраться. Пока вижу нытьё не "асиливших" объектно-ориентированный подход.. ::))

>Кто здесь "troll" это надо ещё разобраться. Пока вижу нытьё не >"асиливших" объектно-ориентированный подход.. ::))

Да, вы совершенно правы! Это очень сложный подход. И мы никак не можем его осилить...

P.S. Я вот только думаю-а на.уя?

> Понятия не имею. :) Меня вполне устраивает процедурно-структурный подход и работа с объектами, как в Glib/GTK+.

А меня не устраивает. Аргументы есть??

> Значит, C осилить легко, а C++ - сложно, правильно я понял? Тогда в чём преимущество C++? ;) Я почему-то думал, что вы нам об удобстве рассказываете... ;)

Объектный подход не всем даётся, согласен.

> Открою секрет - не все программисты на C пользуются vala. :))

Ну да, Вы - исключение ::))

> Да что вы говорите! А производительность тоже может быть какой угодно? ;)

Ну тогда ассемблер решает ::))

> Пока вижу нытьё не "асиливших" объектно-ориентированный подход..

Мальчег, ты смешной. :)) Безосновательно поливать дерьмом то, о чем понятия не имеешь, только у тебя получается. :))

> А меня не устраивает. Аргументы есть??

Ага, именно для таких, как вы, ОО-кодогенераторы и пишутся. :))

> Да, вы совершенно правы! Это очень сложный подход. И мы никак не можем его осилить...

Это ваши личные проблемы, зачем тогда писать _это_ , да ещё в топике про kde? Только в целях троллизма..

> Мальчег, ты смешной. :)) Безосновательно поливать дерьмом то, о чем понятия не имеешь, только у тебя получается. :))

Можно нескромный вопрос.. Что ты делаешь в топике про kde??!!

> Ага, именно для таких, как вы, ОО-кодогенераторы и пишутся. :))

Меньшинство подчиняется большинству ::))

>Понятия не имею. :) Меня вполне устраивает процедурно-структурный подход и работа с объектами, как в Glib/GTK+.

вручную назло С++ прописывать конструкторы-деструкторы - эта да :)

>Тогда в чём преимущество C++? ;) Я почему-то думал, что вы нам об удобстве рассказываете... ;)

Сравни код С++ и то, что получается на выходе любого кодогенератора, если ещё не дошло

>Открою секрет - не все программисты на C пользуются vala. :))

да, только веселые гномеры :)

>Да что вы говорите! А производительность тоже может быть какой угодно? ;)

Производительность любой ООП-С++ программы выше, чем аналогичной из выхода любого псевдо-ООП генератора.

>> Да, вы совершенно правы! Это очень сложный подход. И мы никак не можем >>его осилить...

>Это ваши личные проблемы, зачем тогда писать _это_ , да ещё в топике про >kde? Только в целях троллизма..

Ну после всего того "троллизма" который был до этого... А написано это в ответ на ваш пост про "ниасиливших ООП".

> Ну после всего того "троллизма" который был до этого... А написано это в ответ на ваш пост про "ниасиливших ООП".

Это был ответ на критику ООП, так что яйцо было раньше ::))

> Можно нескромный вопрос.. Что ты делаешь в топике про kde??!!

Логично предположить, что читаю про KDE. Но если уже тема дискуссии зашла так далеко... ;)

ГЫГЫ!

А кто-то сомневался, что так оно и будет? :)

ГЫГЫ! - сказал удовлетворенно geek. Флейм удался на славу. (А в первом своем посте он сказал "бгыгы", к чему бы это?)

Вы теряете нить дискуссии. ;)

>> Понятия не имею. :) Меня вполне устраивает процедурно-структурный подход и работа с объектами, как в Glib/GTK+.

> вручную назло С++ прописывать конструкторы-деструкторы - эта да :)

Перефразирую - я не переписываю вручную конструкторы/деструкторы. В C, вообще, таких понятий нет.

>> Тогда в чём преимущество C++? ;) Я почему-то думал, что вы нам об удобстве рассказываете... ;)

> Сравни код С++ и то, что получается на выходе любого кодогенератора, если ещё не дошло

Это был ответ на тему "ниасиливших" C++.

>> Открою секрет - не все программисты на C пользуются vala. :))

> да, только веселые гномеры :)

Тоже перефразирую - не все разработчики GNOME (программисты на C) пользуются vala.

>> Да что вы говорите! А производительность тоже может быть какой угодно? ;)

> Производительность любой ООП-С++ программы выше, чем аналогичной из выхода любого псевдо-ООП генератора.

Это был ответ на тему библиотек низкого уровня, типа libpng, libgpeg, libxrender. Если покажете мне в них код, сгенерированный "псевдо-ООП генератором", то я с вами соглашусь.

Да и вообще, что-то я наблюдаю у вас нездоровый интерес к кодогенераторам. ;)

> Логично предположить, что читаю про KDE. Но если уже тема дискуссии зашла так далеко... ;)

Куда уж дальше ::))

Отряд не заметил потери бойца (geek-a), и Яблочко песню пропел до конца...

> Перефразирую - я не переписываю вручную конструкторы/деструкторы. В C, вообще, таких понятий нет.

Поэтому и приходится переписывать, т.к. нет.

> Тоже перефразирую - не все разработчики GNOME (программисты на C) пользуются vala.

Зато используют gtkmm ::))

>Перефразирую - я не переписываю вручную конструкторы/деструкторы. В C, вообще, таких понятий нет.

не нужно перефразровать, ты совсем не хочешь понять, что я тебе хочу донести: в gtk по сравнению с qt контсрукторы (процедуры инициализаци и уничтожения объектов) нужно объявлять и задавать в диспатчере объектов вручную, начиная с этих моментов Си начинает сливать С++ в более-менее объемных gui-приложениях

>Это был ответ на тему библиотек низкого уровня, типа libpng, libgpeg, libxrender. Если покажете мне в них код, сгенерированный "псевдо-ООП генератором", то я с вами соглашусь.

ты съезжаешь, т.к. я отвечал на

>А производительность тоже может быть какой угодно? ;)

что есть явный намек на ходящие в рядах хардкорных труЪ-СИoниcтoв легедны о тормознутости с++ программ

>Сравни код С++ и то, что получается на выходе любого кодогенератора, если ещё не дошло

это не говорит ниачом. Вот если ты мне сравнишь codegenerator mega.MetaC|gcc -S - с g++ -S mega.cpp, тогда еще может быть, а так низачод.

В C++ что по твоему делает VTable? это тот самый указатель на this который у тебя так сильно сжирает производительность. Inline методы работают только для невиртуальных , часто невиртуальные методы встречаются в реальной объектной модели C++ ?

И странно что ты не слышал про тот набор оптимизаций в llvm-gcc из-за которого llvm заруливает просто нативный gcc. Ну да скачай и убедись сам.

> Производительность любой ООП-С++ программы выше, чем аналогичной из выхода любого псевдо-ООП генератора.

прямо-таки любой? Ну напиши-ка мне reflection и интроспекцию на C++ без шаблонов и вложенных классов (они ведь так непроизводительны). Возьмем тот же пример из Фаулера: создать объекты классов, которые определяются по данным строки из файла.

//captcha: shoked

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

даа, ну и бенчмарки у ГСМов -- сравнивать длину исходников )))

> Пока вижу нытьё не "асиливших" объектно-ориентированный подход.. ::))

тсс, это большой сикред, но объектно-ориентированно можно программировать хоть на ассемблере ))

Как раз к моему дню рождения выйдут! Крюто!

> тсс, это большой сикред, но объектно-ориентированно можно программировать хоть на ассемблере ))

гланды тоже можно через ж. удалять ::))

>Вот если ты мне сравнишь codegenerator mega.MetaC|gcc -S - с g++ -S mega.cpp, тогда еще может быть, а так низачод.

заплати - тогда сравню :)

>В C++ что [...] модели C++ ?

юзай костыли

>И странно что ты не слышал про тот набор оптимизаций в llvm-gcc из-за которого llvm заруливает просто нативный gcc

это каким макаром к С/GTK vs. C++/QT относится?

>Ну напиши-ка мне reflection и интроспекцию на C++ без шаблонов и вложенных классов (они ведь так непроизводительны).

шаблоны отъедают лишь compile-time, наряду с прямым наследованием (это влоденные классы?) - самые производительные решения

>Возьмем тот же пример из Фаулера: создать объекты классов, которые определяются по данным строки из файла.

любая динамика очень зависит от реализации, бездумно опираться на языковые конструкции - ламерство

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

и тебе посоветую: сгенерируй код на vala и с++ и оцени процедуры инициализации объектов, соотв.- длину asm-листингов

>даа, ну и бенчмарки у ГСМов -- сравнивать длину исходников )))

хм, а у тебя это - количество закрывающих скобок? :-D

>>про возможности кастомизации мы с adarovsky собаку съели, выясняя как добавить генерацию тумб fb2 и djvu в кде =)

Элементарно, Ватсон. Пишешь KImageIO плагин, который в худшем случае будет вызывать ddjvu. Плагин займёт строчек 50. Работы на час от силы.

>по итогам обсуждения - он вообще не нужен, а Qt и KDE - недоразумения =)

Нет. По итогам обсуждения гику с++ не нужен, а Qt и KDE всегда найдут своего потребителя.

> Нет. По итогам обсуждения гику с++ не нужен, а Qt и KDE всегда найдут своего потребителя.

Это было понятно уже давно. Вопрос только в том, какой смысл во всех этих представлениях?? Если бы он писал строчки кода, то хоть какая-то польза была бы. А так через пару дней этот тред уйдёт за пределы главной страницы и нах. никому не будет нужен.

>Это было понятно уже давно. Вопрос только в том, какой смысл во всех этих представлениях?? Если бы он писал строчки кода, то хоть какая-то польза была бы. А так через пару дней этот тред уйдёт за пределы главной страницы и нах. никому не будет нужен.

Да может он что-нибудь и пишет...

> Да может он что-нибудь и пишет...

Хеллоу ворды на си ::))

>Элементарно, Ватсон. Пишешь KImageIO плагин, который в худшем случае будет вызывать ddjvu. Плагин займёт строчек 50. Работы на час от силы.

=))))

ну нет у меня kde*-dev, qt-*dev и прочего говна. Чтобы решить элементарную задачу в пару строчек на баше - надо всё это ставить? бугага

>вручную назло С++ прописывать конструкторы-деструкторы - эта да :)

я не понял - ты тут хвастаешься, что не знаешь ни C, ни glib, ни Vala? =)

>Сравни код С++ и то, что получается на выходе любого кодогенератора, если ещё не дошло

сравнил. Код на C - прозрачен и понятен. Код на плюсах...ну хер знает, мож где-то в хидерах операторы перегрузили - проверю и скажу

:)

>Производительность любой ООП-С++ программы выше, чем аналогичной из выхода любого псевдо-ООП генератора.

бугага

> заплати - тогда сравню :)

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

>прямым наследованием (это влоденные классы?)

путаемся в понятиях?

>шаблоны <..> - самые производительные решения

давай применим твой же бенчмарк на длину исходников. У тебя есть 10 классов, 10 уточений классов (например, аналог аспектов пишем. Ну или посмотри в ATL). Разверни шаблоны двойной-тройной вложенности, посмотри на C код в который это разворачивается, ужаснись. Теперь напиши десять строчек на Смоллтоке, с динамической типизацией. Что круче, десять строчек или 10х10=100?

>>Возьмем тот же пример из Фаулера: создать объекты классов, которые определяются по данным строки из файла. >любая динамика очень зависит от реализации, бездумно опираться на языковые конструкции - ламерство

повторяем тест имени frame : смотрим пример Фаулера на C# (там есть языковые конструкции для рефлексии), три экрана; смотрим лисп-исходник аналогичного решения, 20 строчек. А теперь злорадно хохочем и смотрим на frame, который будет изображать решение на C++, где "языковых конструкций" нет (ну или не будет, если не знает, как это делается). Сюрприз, языковых конструкций нет, а рефлексия -- есть.

Так что ты сам себе проигрываешь по собственным бенчмаркам :))

>ну нет у меня kde*-dev, qt-*dev и прочего говна.

apt-get не осилил?

> Чтобы решить элементарную задачу в пару строчек на баше - надо всё это ставить? бугага

Да какой тебе баш. Сначала man apt-get освой!! ::))

> сравнил. Код на C - прозрачен и понятен.

А уж на ассемблере то как всё просто, ни одному убогому сишнику даже и не снилось ::))

>apt-get не осилил?

мальчик, зачем мне apt-get и куча говна, если ту же задачу я могу решить в пару строчек на любом скриптовом языке? :) Только затем, чтобы убедиться, что в кде можно тумбнайлеры добавлять? Так я это получше тебя знаю =)

>А уж на ассемблере то как всё просто, ни одному убогому сишнику даже и не снилось ::))

думаешь смешно? Смейся, неудачник, ассемблер на самом деле простой язык. Проще некуда =)

> мальчик, зачем мне apt-get и куча говна,

Правильно, rpm и кеды - рулят :;))

>если ту же задачу я могу решить в пару строчек на любом скриптовом языке? :)

А на tcl!!???

Только затем, чтобы убедиться, что в кде можно тумбнайлеры добавлять? Так я это получше тебя знаю =)

Знать не значит уметь ::))

> думаешь смешно? Смейся, неудачник, ассемблер на самом деле простой язык. Проще некуда =)

А что же ты как последний лузир на си да на си, осваивай ассемблер!!!

>А на tcl!!???

и на tcl можно. Хотя слишком черезжопный язык. Имхо

>Знать не значит уметь ::))

ну ты-то даже не знаешь =)

>А что же ты как последний лузир на си да на си, осваивай ассемблер!!!

дык освоил, когда тебя ещё в проекте не было =)

> и на tcl можно. Хотя слишком черезжопный язык. Имхо

Доказательства будут?

> ну ты-то даже не знаешь =)

а ты в этом уверен?

> дык освоил, когда тебя ещё в проекте не было =)

Откуда такая трава?

> баг с раскладкой
ну не пытайся вешать на alt+shift
обычно пользователям я вешаю на shift + tab все прекрасно работает, можно ставить сколько угодно раскладок и любые комбинации

>Доказательства будут?

доказательства черезжопности? =)

>а ты в этом уверен?

практически да

>Откуда такая трава?

из статистики =)

>доказательства черезжопности? =)

Нет, рабочий пример кода ::))

> практически да

а я вот теоретически нет ::))

> из статистики =)

Согласен, статисты всегда курят всякую дрянь, так что ты не исключение ::))

>Нет, рабочий пример кода ::))

exec ffmpeg блаблабла :)

>а я вот теоретически нет ::))

бывает =)

>Согласен, статисты всегда курят всякую дрянь, так что ты не исключение ::))

статисты к статистике отношения не имеют =)