Я в восторге от будущего GNOME

вот уж не надо. киото - не проект кде.орг, и не часть 4х кед. хорошо если на нем хоть одно приложение написано.

но это замечательный пример как продуманный дизайн позволяет с легкостью сделать биндинги на любом языке - хоть руби, хоть с#, хоть <подставте свой язык>.

основные работы в кде4.0 - по прежнему с++ и куте.

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

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

>В винде даже цвет синего экрана можно было в реестре поменять

Где?!?!?!?!? :-D

>вот уж не надо. киото - не проект кде.орг,

а mono и gtk*-sharp - проекты gnome.org, да? :)

>а по поводу того что моно не часть гнома - тут как раз наоборот. очень многие компоненты гнома жестко завязаны на моно.

перечисли.

>Где?!?!?!?!? :-D

Была какая-то программа-твикер, с тысячами параметров. Вроде называлась X-setup. Один из твиков - выбор цвета фона и текста БСОДа (из стандартной 16-цветной палитры). У меня был зеленый текст на черном фоне ;)

Правда, это я пробовал только на 98-ом маздае, насчет 2к, ХРюнделя или быдловисты не знаю.

>В винде даже цвет синего экрана можно было в реестре поменять

(насторожился)

> Была какая-то программа-твикер, с тысячами параметров. Вроде называлась X-setup. Один из твиков - выбор цвета фона и текста БСОДа (из стандартной 16-цветной палитры). У меня был зеленый текст на черном фоне ;)

Под слакой работает?

А, без твикеров можно, просто system.ini

http://www.petri.co.il/change_bsod_color.htm

Ужос.

> 1. Объект первого класса;

Само по себе преимуществом не является

> 2. Типизирован.

Функция тоже

> Проще, чем разбираться с указателями на функции;

Это просто набор слов.

> 3. Плюшки ООП типа того же наследования;

Для _функций_? функтор реализуется методом, как наследование позволит тебе изменить _метод_? Обернуть, заменить на другой - да, но всё это можно сделать и с обычной функцией.

> 4. Больше возможностей: счетчики использования,

Хм, а это часто нужно?

> реализация генераторов;

Этого не понял. Имеется в виду, что у функции есть какое-то внутреннее состояние, сохраняющееся между вызовами?

> 5. Больше возможностей отладки. Без каких-то проблем можно давать юзеру две версии: "рабочую" и "отладочную";

То же и с обычными функциями

> 6. Выше гибкость см. идиому Strategy (Александреску)

Книги под рукой нет.

Итого - 1 явное преимущество (генераторы), и одно сильно условное - счетчики. Не густо. К тому же следует учесть, что простых случаев (функция реализует алгоритм и не имеет побочных эффектов) - большинство.

> У кде тоже косметическкий ... берюлек-свистелок понавешали и все... и еще qt4

4.2. Читаем про Solid, Phonon, Nepomuk.

> _Сейчас_ там реестре нет, есть набор конфиг файлов и парсер к ним. А вот в 4-ке будет, да.

Сергей, про sycoca не забывай. ;)

> Сергей, про sycoca не забывай. ;)

К счастью, это не реестр в определении ЛОРовцев. :) Реестр - это то, что похоже на regedit, ты забыл? :)

> Теперь я думаю, что я ошибался :)

Может он и в этот раз ошибается?

>Само по себе преимуществом не является

Как это не является?

>Функция тоже

Но с типами функций работать намного сложнее

>Это просто набор слов.

Ни разу! operator() может быть и перегруженным, в отличие указателя на функцию, где ты должен определить все его параметры

>Этого не понял. Имеется в виду, что у функции есть какое-то внутреннее состояние, сохраняющееся между вызовами?

Да

>Обернуть, заменить на другой - да, но всё это можно сделать и с обычной функцией.

Да кто ж спорит? Только обычно функция реализуется в виде нескольких связанных функций. Согласись, что в рамках идиомы Functor это делать намного приятнее.

>То же и с обычными функциями

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

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

А бывает что и нет. И никогда ты не знаешь, понадобится тебе использовать Functor или нет. А если понадобиться - менять определения по "поиск" - "замена"? Или сразу использовать. Тем более, если функция реализует какой-либо алгоритм.

> Как это не является?

Ну а в чем преимущество для функции без побочных эффектов и внутреннего состояния?

> с типами функций работать намного сложнее

O_O

> в рамках идиомы Functor это делать намного приятнее.

Для функций без побочных эффектов и внутреннего состояния - никакой разницы.

> если вдруг требуется использовать "пользовательский" класс который собирает отладочную информацию?

Я собираю ее с помощью логгинга и отладчика. Зачем для этого какие-то новые классы?

> И никогда ты не знаешь, понадобится тебе использовать Functor или нет.

Напомню одно из разумных правил XP: не реализовывайте функциональность "впрок" - она может вам не понадобиться. Ну а адаптеры, делающие и функций функторы, давно придуманы.

>4.2. Читаем про Solid, Phonon, Nepomuk.

Вот нафига нужен Phonon? Неужели нельзя просто дописать aRts?... Бедные девелы wine - столько хлама им надо имплементировать... :'(

А зачем aRts? Phonon - почитай, что это такое, а потом делай заявления.

причем тут wine? что касается звука, wine прекрасно работает с alsa

>Phonon

кто нибудь знает, зачем над уже имеющейся и использующейся везде абстракцией кодеков (gstreamer) строить еще одну абстракцию?

> кто нибудь знает, зачем над уже имеющейся и использующейся везде абстракцией кодеков (gstreamer) строить еще одну абстракцию?

почему еще никто не вспомнил про велосипеды? ;)

>почему еще никто не вспомнил про велосипеды? ;)

ну почему же никто...а ты? :)

> ну почему же никто...а ты? :)

а я про них и не забывал =)

>wine прекрасно работает с alsa

Но еще лучше работает с OSS (см. статсы на на их сайте)

А никто не пояснит, почему бы не стоило смотреть на мону вместо Vala? Или у моно биндингов все еще мало для гнома?

знаю, у меня iTunes через алсу заикается иногда, а через осс все как надо

>В винде даже цвет синего экрана можно было в реестре поменять

Да и сейчас можно... И если только флеймить на LOR, то ещё долго будет можно.

Слои абстракций -- вещи полезная. Не будет же каждая прога по своему в дсп писать. В идеале все устройства должны быть абстрагированы до уровня виртуальных велосипедиков, тогда не придётся изобретать велосипеды-мутанты.

> Слои абстракций -- вещи полезная. Не будет же каждая прога по своему в дсп писать. В идеале все устройства должны быть абстрагированы до уровня виртуальных велосипедиков, тогда не придётся изобретать велосипеды-мутанты.

мне непонятна затея создать абстракцию над абстракцией

>А никто не пояснит, почему бы не стоило смотреть на мону вместо Vala?

потупить решил, да?

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

>Вникать самому лень и сейчс некогда, да. Так в чем причина ключевые слова?

тред перечитай. Раз десять уже разжевал, что такое Vala и зачем оно нужно. Заипали глупости друг за другом повторять

> Заипали глупости друг за другом повторять

Судя по реакции, вменяемого ответа и не было?

>кто нибудь знает, зачем над уже имеющейся и использующейся везде абстракцией кодеков (gstreamer) строить еще одну абстракцию?

Gstreamer - не единственный backend, еще будет Xine и, возможно, что-то еще. Понятно?

> мне непонятна затея создать абстракцию над абстракцией

Просто со временем приходят какие-то новые идеи, реализуются новые механизмы. Не ломать же уже работающий уровень, который архитектурно эти новые идеи не тянет. Никто же не запретит когда-либо написать новый велосипедик, который заменит сразу несколько уровней абстракции, без архитектурных детских болезней.

разумно

> А никто не пояснит, почему бы не стоило смотреть на мону вместо Vala? Или у моно биндингов все еще мало для гнома?

Поддерживаю тебя. Vala - убогое препроцессорное гавно. Когда они запустят дебаггер, то увидят километровые листинги сишного сгенерированного кода. Отлаживатся в этой помойке - одно "удовольствие". Моно несмотря на ненавистный ГЦ и некрософтовские корни выглядит для программиста гораздо более привлекательно. Но с другой стороны напрашивается вопрос, зачем все эти костыли Vala, Моно, когда можно сразу писать на православном С++? KDE основанный на QT в этом отношении гораздо более удобен для программера, чем гном со своим говнотулкитом.

>Судя по реакции, вменяемого ответа и не было?

был. И не один раз. Если ты считаешь, что я каждому, кто поленился в _этом_ _же_ _треде_ поискать ответы на свои вопросы, буду повторять одно и тоже - ты крепко ошибаешься.

>зачем все эти костыли Vala, Моно, когда можно сразу писать на православном С++?

православный С++...ггг...спасибо, давно так не ржал =)

Вопрос собсно такой - чем препроцессор C без runtime requrements так уж лучше моны и C# - а не что *такое* Vala.

>Напомню одно из разумных правил XP: не реализовывайте функциональность "впрок" - она может вам не понадобиться. Ну а адаптеры, делающие и функций функторы, давно придуманы.

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

Лично я привык, что функцию можно присваивать, возварщать, хешировать, и считаю что все выше приведенное - Хорошая Вещь. Кто-то, возможно, привык к другому подходу.

Functor - позволяет преодолеть некоторые ограничения C++. Более того, позволяет создавать функции высших порядков, что может достаточно серьезно потеснить не слишком удачную реализацию идиомы Iterator в С++, хотя признаюсь, что подобных подходов я не встречал.

Functor дает дополнительные возможности без ощутимой потери производительности: сбор статистики, гибкий вывод отладочной информации, возможность настройки во время исполнения программы, возможность настройки через механизм шаблонов C++, облегчает написание тестов. Все вышеперечисленное используется в подходе XP.

Так что если по каким-то причинам в проекте на C++ используются сишные функции, можно подумать об использовании вместо них идиомы Functor.

> почему еще никто не вспомнил про велосипеды? ;)

Погода уже вторую неделю нелётная, сегодня первый нормальный день, а ещё и выпить за солнышко нужно.

>чем препроцессор C без runtime requrements так уж лучше моны и C#

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

> Functor дает дополнительные возможности без ощутимой потери производительности

Это ложная мотивация.

P.S. почему ещё никто из высказавшихся выше не срифмовал со "сфинктером"?

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

Чем бы дите не тешалось, лишь бы не вешалось...

Чем с++ не угодил, а?

> Лично я привык, что функцию можно присваивать, возварщать, хешировать, и считаю что все выше приведенное - Хорошая Вещь. Кто-то, возможно, привык к другому подходу.

Ты просто не осилил нормальный полиморфизм и правильный классовый-дизайн. В моем проекте указатели на функцию используются только в качестве коллбэков в ГУЕ. А функторы только в качестве визиторов по дереву. При этом вспомогателььных статических функций немерянное количество. Совершено не вижу причин юзать функторы там где они не нужны.

>Когда они запустят дебаггер, то увидят километровые листинги сишного сгенерированного кода.

А зачем пускать дебаггер на "обертке"? Vala, не рассчитан что на нем будут разрабатывать что-то сложное. Он даже, при всем уважении к разработчикам не тянет на язык системной интеграции. Vala нужно рассматривать исключительно как простенький DSL для работы с GObject.

Действительно, почитай внимательно топик.

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

Вот что-то мне и кажется, что может быть рпроще потерпеть биндинги и рантаймы, чем такую заморочку?

>почему ещё никто из высказавшихся выше не срифмовал со "сфинктером"?

О да, супер аргумент! А давайте:

Гном-гастроном

Линус-минус

Гарик-нарик

Бластер-пластырь

> Чем с++ не угодил, а?

C++ не подходит для людей страдающих фимозом головного мозга.

>Чем с++ не угодил, а?

давай, покажи, как ты в C++ сделаешь GObject ABI. Троллить не надоело, умник?

> А зачем пускать дебаггер на "обертке"? Vala, не рассчитан что на нем будут разрабатывать что-то сложное. Он даже, при всем уважении к разработчикам не тянет на язык системной интеграции. Vala нужно рассматривать исключительно как простенький DSL для работы с GObject.

Ты наркоман штоле? Зачем он тогда нуже вообще к томуже компилируемый. Для простенького DLS гораздо удобнее использовать интерпретируемый язык не требующий компиляции.