Здравствуйте, criosray, Вы писали:

ГВ>>И это очень хорошо, что не нужно напряженно следить за настроениями в комитете. Нет, это (читай по буквам) О Ч Е Н Ь хорошо.
C>Это очень плохо. Язык должен развиваться. Посмотрите на С# — кому плохо, что за эти 7 лет на пороге уже 4ая версия языка, где каждая версия — серьезный шаг вперед?..
язык C++ в своей молодости тоже бурно развивался, почитай D&E, только вот когда количество программистов на нём выросло до миллионов, количество платформ и компиляторов до десятков, то тут уже начинает главенствовать принцип "не навреди". C#, дай бог ему здоровья, если обретёт такой же ареал то будет развиваться тоже не шустро, уж поверь.

Здравствуйте, Mamut, Вы писали:

ГВ>> Тут вопрос в другом: удалось реализовать фичу X средствами самого языка ("понятно какими" или "непонятно какими" — совершенно не важно) или нет. Если не удалось — значит возможностей языка для этой фичи не хватает. Если удалось, то относить сей факт к "недостаткам" можно, ИМХО, только по каким-то очень вычурным соображениям вроде очередного "миллиона индусов, которые завалят нас багами".

M>Все Тьюринг-полные языки равны друг другу по возможностям (ну то есть то, что решается одной строчкой на Хаскеле, можно решить тысячью строк на ассемблере). Другой вопрос — а надо ли, и не взять ли в руки инструмент, котороый повышает эффективность разработки?

А кто-то с этим спорит? По-моему, тут грызня о мифических фатальных недостатках C++ и тех, кто на нём программирует. Собственно, пропоненты такой позиции, ИМХО, традиционно поступают в строгом соответствии с советами Тристана:

Если вы на женщин слишком падки,
В прелестях ищите недостатки.
Станет сразу все намного проще:
Девушка стройна, мы скажем: мощи!

Умницу мы наречем уродкой,
Добрую объявим сумасбродкой.
Ласковая — стало быть, липучка,
Держит себя строго — значит, злючка.

Назовем кокетливую шлюхой,
Скажем про веселую — под мухой.
Пухленькая — скоро лопнет с жиру,
Щедрую перекрестим в транжиру.

Ну, а бережлива? — Окрестим в сквалыгу!
Если маленькая? — Ростом с фигу!
Если рослая? — Тогда верзила!

(c)

Здравствуйте, Хвост, Вы писали:

ГВ>>>И это очень хорошо, что не нужно напряженно следить за настроениями в комитете. Нет, это (читай по буквам) О Ч Е Н Ь хорошо.
C>>Это очень плохо. Язык должен развиваться. Посмотрите на С# — кому плохо, что за эти 7 лет на пороге уже 4ая версия языка, где каждая версия — серьезный шаг вперед?..
Х>язык C++ в своей молодости тоже бурно развивался, почитай D&E, только вот когда количество программистов на нём выросло до миллионов, количество платформ и компиляторов до десятков, то тут уже начинает главенствовать принцип "не навреди". C#, дай бог ему здоровья, если обретёт такой же ареал то будет развиваться тоже не шустро, уж поверь.

Если бы Вы что-то знали о С# и об Андерсоне, Вы бы не писали такой чуши.

Здравствуйте, criosray, Вы писали:

Х>>язык C++ в своей молодости тоже бурно развивался, почитай D&E, только вот когда количество программистов на нём выросло до миллионов, количество платформ и компиляторов до десятков, то тут уже начинает главенствовать принцип "не навреди". C#, дай бог ему здоровья, если обретёт такой же ареал то будет развиваться тоже не шустро, уж поверь.

C>Если бы Вы что-то знали о С# и об Андерсоне, Вы бы не писали такой чуши.

Интересно, почему?

Здравствуйте, criosray, Вы писали:

Х>>язык C++ в своей молодости тоже бурно развивался, почитай D&E, только вот когда количество программистов на нём выросло до миллионов, количество платформ и компиляторов до десятков, то тут уже начинает главенствовать принцип "не навреди". C#, дай бог ему здоровья, если обретёт такой же ареал то будет развиваться тоже не шустро, уж поверь.
C>Если бы Вы что-то знали о С# и об Андерсоне, Вы бы не писали такой чуши.

Ганс Христиан? Как же, знаком, знаком. "Принцесса на горошине", "Дюймовочка", "Гадкий утёнок", да что там, "Стойкий оловянный солдатик", ето же всё классика и знакома каждому.
А по существу, в чём чушь? Удиви меня.

Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>>>Вопрос остаётся тем же самым: сколько это будет стоить пользователю.
C>>Стоимость прямо пропорциональна человеко-часам, затраченым в процессе разработки и в этом плане С++ уже давно в отстающих, при чем иногда очень-очень сильно отстающих...
ГВ>Началось... Давай вспомним все значения слова "стоимость" и все контексты, к которым его можно привязать.
Началась демогогия... Вам есть что по делу сказать?

ГВ>>>В новой версии стандарта — поддерживает.
C>>Поддерживает 1% от ФЯ? Замечательно.

ГВ>Ух ты. А что это такое — 1% от ФЯ? А почему не 0,76% и не 3,84%?

Еще одна порция демагогии. По делу нечего сказать? Под 1% подразумевалась — малая доля, если Вы ничего больше придумать не можете, кроме как цепляться к словам.
Функциональщины в том же С# больше, чем в С++0х (хорошее название, кстати, точно выражает инопланетное происхождение синтаксиса языка), но это не делает С# функциональным языком.

ГВ>>>А так — да, бесспорно. На Lisp можно написать очень много всего интересного. Если бы ещё не потеря производительности по сравнению с "убогим" C/C++ — всё было бы совсем хорошо.
C>>Представьте себе, среди всего многообразия задач очень мало таких, для которых важно выжимать максимальную производительность.

ГВ>Это как-то опровергает то, что Lisp медленнее C++?

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

C>>Лучшее — враг хорошего.

ГВ>Бесспорно. На C++ получаются вполне хорошие решения.

Смотря по каким критериям оценивать и в зависимости от задач.

ГВ>>>Забавно, что как раз использование "побочных эффектов" и делает C++ столь привлекательным по критерию производительности программиста при сохранении производительности продукта.
C>>А вот это иллюзии. В программировании крайне важно сохранять "читабельность кода". Ради этого придумывают много умных терминов вроде SRP, DRY, SoC, Open/close principle, cohesion и т.д. и т.п.
ГВ>С кем-то я совсем недавно спорил по поводу читабельности... А, с Владом как раз. Давай, теперь с тобой. Что такое "читабельность"? Какова связь читабельности и, например, open/close principle?
Самая что ни есть прямая.

ГВ>>>А чистота "метапрограммирования", или "функционального программирования", или ещё какая "чистота" какой-нибудь очередной мутной "парадигмы" вообще не шибко-то кого и беспокоит (в мире C++).
C>>и это заметно. Чистота вообще не шибко кого заботит в мире С++ и появляются на свет уродливые творения, где над каждой строкой кода надо раздумывать так же долго, как при чтении Ницше...
ГВ>Вот те раз, а мужики-то и не знают, что "лёгкость понимания", оказывается, зависит от чистоты парадигмы.
Легкость понимания зависит от выразительности и лаконичности синтаксиса языка и структуры кода (и других менее значимых факторов). В этом плане С++, скажем прямо, сосет. И Ваша реализация IoC тому самое явное доказательство (для сравнения смотрите исходник Сastle MicroKernel).

ГВ>>>Ну, что тут скажешь? Я занесу в шпаргалку Абсолютных Противо-C++-ных Аргументов ещё слова: "ересь", "бред" и "вера".
C>>Занесите, т.к. Влад абсолютно прав. С++ уродливый и непродуктивный язык и жив он все еще только потому, что у него есть ниша, в которой у него нет достойных конкурентов.

ГВ>Следовательно, для этой ниши C++ вполне подходящий и продуктивный язык, где ему нет достойных конкурентов.

На безрыбьи и рак — щука.

ГВ>>>И это очень хорошо, что не нужно напряженно следить за настроениями в комитете. Нет, это (читай по буквам) О Ч Е Н Ь хорошо.
C>>Это очень плохо. Язык должен развиваться. Посмотрите на С# — кому плохо, что за эти 7 лет на пороге уже 4ая версия языка, где каждая версия — серьезный шаг вперед?..

ГВ>Будь я разработчиком компилятора того же C++, меня такая ситуация очень бы устраивала (стабильность спецификации).

Какой процент разработчиков компилятора от общего числа программистов?

Здравствуйте, Хвост, Вы писали:

Х>>>язык C++ в своей молодости тоже бурно развивался, почитай D&E, только вот когда количество программистов на нём выросло до миллионов, количество платформ и компиляторов до десятков, то тут уже начинает главенствовать принцип "не навреди". C#, дай бог ему здоровья, если обретёт такой же ареал то будет развиваться тоже не шустро, уж поверь.
C>>Если бы Вы что-то знали о С# и об Андерсоне, Вы бы не писали такой чуши.

Х>Ганс Христиан? Как же, знаком, знаком. "Принцесса на горошине", "Дюймовочка", "Гадкий утёнок", да что там, "Стойкий оловянный солдатик", ето же всё классика и знакома каждому.
Опечатка. Подразумевался Андерс. Андерс Хайлсберг.
Х>А по существу, в чём чушь? Удиви меня.
В том, что для С# никогда не будет "десятков компиляторов и платформ" — язык будет продолжать развиваться во много раз быстрее С++ до тех пор, пока будет куда развиваться, а путей развития для него все еще — море.

Здравствуйте, criosray, Вы писали:

ГВ>>Началось... Давай вспомним все значения слова "стоимость" и все контексты, к которым его можно привязать.
C>Началась демогогия... Вам есть что по делу сказать?

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

ГВ>>Ух ты. А что это такое — 1% от ФЯ? А почему не 0,76% и не 3,84%?
C>Еще одна порция демагогии. По делу нечего сказать? Под 1% подразумевалась — малая доля, если Вы ничего больше придумать не можете, кроме как цепляться к словам.
C>Функциональщины в том же С# больше, чем в С++0х (хорошее название, кстати, точно выражает инопланетное происхождение синтаксиса языка), но это не делает С# функциональным языком.

Прости, а кто-то утверждал, что C++ — функциональный язык? Говорили, что он поддерживает функциональный стиль. Это несколько не одно и то же. Не надо додумывать, а потом спорить с додуманным.

ГВ>>Это как-то опровергает то, что Lisp медленнее C++?
C>Нет, это означает что во многих (в большинстве, коли Вам так будет угодно) контекстах аргумент производительности конечного продукта абсолютно иррелевантет.

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

C>>>Лучшее — враг хорошего.
ГВ>>Бесспорно. На C++ получаются вполне хорошие решения.
C>Смотря по каким критериям оценивать и в зависимости от задач.

+1

ГВ>>С кем-то я совсем недавно спорил по поводу читабельности... А, с Владом как раз. Давай, теперь с тобой. Что такое "читабельность"? Какова связь читабельности и, например, open/close principle?
C>Самая что ни есть прямая.

Сначала ответь на первый вопрос: что такое "читабельность"?

ГВ>>Вот те раз, а мужики-то и не знают, что "лёгкость понимания", оказывается, зависит от чистоты парадигмы.
C>Легкость понимания зависит от выразительности и лаконичности синтаксиса языка и структуры кода (и других менее значимых факторов). В этом плане С++, скажем прямо, сосет. И Ваша реализация IoC тому самое явное доказательство (для сравнения смотрите исходник Сastle MicroKernel).

Я разве утверждал, что C++ — лаконичный язык? Его относительная многословность — вполне медицинский факт.

Кстати, что касается IoC, то мы начали с желательной модели использования. И кстати, содержательных комментариев так пока и не последовало.

ГВ>>Следовательно, для этой ниши C++ вполне подходящий и продуктивный язык, где ему нет достойных конкурентов.
C>На безрыбьи и рак — щука.

Да ну? Разве ж C++ — это безрыбье? Безрыбье — это автокод.

ГВ>>Будь я разработчиком компилятора того же C++, меня такая ситуация очень бы устраивала (стабильность спецификации).
C>Какой процент разработчиков компилятора от общего числа программистов?

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

Здравствуйте, Хвост, Вы писали:

Х>>>с использованием етой библиотеки реализуется минут за 5-10 опытными программистами на C++
C>>Вы ведь опытный программист, да? Реализацию в студию.
Х>реализацию чего? пока по вашим постам я только понял что вы хотите что-то вроде service locator'а, а не IoC контейнера. Лучше опишите задачу, как вы её решаете с помощью вашего фреймворка, и посмотрим что в етом случае делают в С++.

Простейший пример из продакшн кода — форма ввода, построенная на Supervising Controller, где презентация отмечена циклом жизни pooled 0-5, а контроллер на 100% (почти) покрыт модульными тестами и таких форм не одна, ни две, а больше сотни.

Здравствуйте, criosray, Вы писали:

C>Здравствуйте, Хвост, Вы писали:

Х>>Здравствуйте, criosray, Вы писали:

C>>>Запредельное? Патерн IoC в управляемых языках реализуется на базовом уровне за минут 40-50 максимум неопытными студентами.
Х>>http://code.google.com/p/pococapsule/

Очень-очень примитивно, если сравнивать с Castle Windsor.
Где возможность задать Lifecycle?
Где возможность задать Lifestyle?
Где автоматическая регистрация компонент по шаблону?

            Scan(x =>
            {
                x.TheCallingAssembly();


                x.ExcludeNamespaceContainingType<IEvent>();
                x.ExcludeNamespaceContainingType<SearchModel>();
                x.ExcludeNamespaceContainingType<AuthenticationService>();
                x.ExcludeNamespaceContainingType<DovetailController>();

 
                x.AddAllTypesOf<IDomainMap>();


                x.WithDefaultConventions();
                x.With<DomainEntityAliaser>();
            });

Где расширяемость аналогичная Сastle Facilities? Где интерцепторы???

Здравствуйте, criosray, Вы писали:

C>>>>Запредельное? Патерн IoC в управляемых языках реализуется на базовом уровне за минут 40-50 максимум неопытными студентами.
Х>>>http://code.google.com/p/pococapsule/
C>Очень-очень примитивно, если сравнивать с Castle Windsor.

Ну дык, pococapsule и по объёму чуть не в 10 раз меньше, чем Castle Windsor. Что тут бочку-то катить? Тем не менее, в качестве ответа на вопрос об IoC — вполне себе ответ.

C>Где возможность задать Lifecycle?
C>Где возможность задать Lifestyle?

Это уже фичи, которые в тот или иной контейнер могут быть внесены или нет.

C>Где автоматическая регистрация компонент по шаблону?

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

C>Где расширяемость аналогичная Сastle Facilities?

Да тоже, вроде бы, ничего сверхъестественного.

C>Где интерцепторы???

Вот с этим сложнее, но и то, из-за кодогенерации.

---

Ты всё же определись, чего ты хочешь от собеседников: чтобы сделали копию Castle Windsor или MS Unity, продемонстрировали возможный подход или ещё чего-то? Я надеюсь — ты не просто ищешь повод фыркнуть погромче, верно? Можно написать IoC-контейнер и конфигурируемый, и гибкий, и с обилием других качеств, но это, в общем, довольно объёмная работа. Тот же Castle Windsor, если судить по объёму исходников, ну никак не один и не два человеко-месяца.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, criosray, Вы писали:

C>>>>>Запредельное? Патерн IoC в управляемых языках реализуется на базовом уровне за минут 40-50 максимум неопытными студентами.
Х>>>>http://code.google.com/p/pococapsule/
C>>Очень-очень примитивно, если сравнивать с Castle Windsor.

ГВ>Ну дык, pococapsule и по объёму чуть не в 10 раз меньше, чем Castle Windsor. Что тут бочку-то катить?
Кого волнует объем?
ГВ>Тем не менее, в качестве ответа на вопрос об IoC — вполне себе ответ.
Нет, это не ответ. Что толку от такого IoC, если у него кроме самого базового DI и нету больше ничего?
Вот Вы лично пользуетесь PocoCapsule? Наверняка нет, а мы IoC используем на каждом шагу потому, что сильно облегчает жизнь и естественным образом улучшает архитектуру систем.

C>>Где возможность задать Lifecycle?
C>>Где возможность задать Lifestyle?

ГВ>Это уже фичи, которые в тот или иной контейнер могут быть внесены или нет.
Ну покажите мне хоть один контейнер на С++, где были бы эти "фичи". Это, кстати, не просто фичи, а самая основа работы контейнера. Что мне толку от контейнера, если я не могу задать lifestyle компоненты?

C>>Где автоматическая регистрация компонент по шаблону?

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

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

C>>Где расширяемость аналогичная Сastle Facilities?

ГВ>Да тоже, вроде бы, ничего сверхъестественного.

Ну нету ведь?

C>>Где интерцепторы???

ГВ>Вот с этим сложнее, но и то, из-за кодогенерации.

Конечно посложнее. И судя по тому, что готовых рабочих решений нету — невыполнимая задача для С++. Так?

ГВ>

---

ГВ>Ты всё же определись, чего ты хочешь от собеседников: чтобы сделали копию Castle Windsor или MS Unity, продемонстрировали возможный подход или ещё чего-то?
Да, я хочу чтоб мне показали аналог Виндсор, но для С++. Еще я хочу увидеть аналог RhinoMocks.

ГВ>Я надеюсь — ты не просто ищешь повод фыркнуть погромче, верно? Можно написать IoC-контейнер и конфигурируемый, и гибкий, и с обилием других качеств, но это, в общем, довольно объёмная работа. Тот же Castle Windsor, если судить по объёму исходников, ну никак не один и не два человеко-месяца.
Для справки, на дотнет реализаций этих контейнеров уже больше десятка (а то и двух десятков). Почему на вашем столь любом замечательном мощном С++ до сих пор нету ничего подобного? Можете ответить на этот вопрос?

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Началось... Давай вспомним все значения слова "стоимость" и все контексты, к которым его можно привязать.
C>>Началась демогогия... Вам есть что по делу сказать?

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

Каких еще ресурсов? Наш вполне себе современный софт с богатым пользовательским интерфейсом (WinForms, и WPF c недавних пор) работает на старых маломощных компьютерах и пользователи им довольны.

ГВ>>>Ух ты. А что это такое — 1% от ФЯ? А почему не 0,76% и не 3,84%?
C>>Еще одна порция демагогии. По делу нечего сказать? Под 1% подразумевалась — малая доля, если Вы ничего больше придумать не можете, кроме как цепляться к словам.
C>>Функциональщины в том же С# больше, чем в С++0х (хорошее название, кстати, точно выражает инопланетное происхождение синтаксиса языка), но это не делает С# функциональным языком.
ГВ>Прости, а кто-то утверждал, что C++ — функциональный язык? Говорили, что он поддерживает функциональный стиль. Это несколько не одно и то же. Не надо додумывать, а потом спорить с додуманным.
Да не поддерживает он функциональный стиль. Хотите функциональный стиль — смотрите тот же F#.

ГВ>>>С кем-то я совсем недавно спорил по поводу читабельности... А, с Владом как раз. Давай, теперь с тобой. Что такое "читабельность"? Какова связь читабельности и, например, open/close principle?
C>>Самая что ни есть прямая.
ГВ>Сначала ответь на первый вопрос: что такое "читабельность"?
Cвойство текстового материала, характеризующее лёгкость восприятия его человеком.

ГВ>>>Вот те раз, а мужики-то и не знают, что "лёгкость понимания", оказывается, зависит от чистоты парадигмы.
C>>Легкость понимания зависит от выразительности и лаконичности синтаксиса языка и структуры кода (и других менее значимых факторов). В этом плане С++, скажем прямо, сосет. И Ваша реализация IoC тому самое явное доказательство (для сравнения смотрите исходник Сastle MicroKernel).
ГВ>Я разве утверждал, что C++ — лаконичный язык? Его относительная многословность — вполне медицинский факт.
"а мужики-то и не знают, что "лёгкость понимания", оказывается, зависит от чистоты парадигмы"

ГВ>Кстати, что касается IoC, то мы начали с желательной модели использования. И кстати, содержательных комментариев так пока и не последовало.
Глаза раззуйте.

ГВ>>>Следовательно, для этой ниши C++ вполне подходящий и продуктивный язык, где ему нет достойных конкурентов.
C>>На безрыбьи и рак — щука.

ГВ>Да ну? Разве ж C++ — это безрыбье? Безрыбье — это автокод.

Нет, на безрыбьи и С++ (рак) — щука.

ГВ>>>Будь я разработчиком компилятора того же C++, меня такая ситуация очень бы устраивала (стабильность спецификации).
C>>Какой процент разработчиков компилятора от общего числа программистов?

ГВ>Меня это устраивало бы, потому что можно сделать высококачественный компилятор и спокойно его отшлифовать, не опасаясь очередного виража стандартизаторов. А не потому, что я нашёл тихую заводь.
Вы не ответили на поставленный вопрос: Какой процент разработчиков компилятора от общего числа программистов?

Здравствуйте, criosray, Вы писали:

ГВ>>Я уж сказал, вроде. Стоимость для конечного пользователя — это, в числе прочего, и стоимость аппаратных ресурсов, необходимых для выполнеия программ.
C>Каких еще ресурсов? Наш вполне себе современный софт с богатым пользовательским интерфейсом (WinForms, и WPF c недавних пор) работает на старых маломощных компьютерах и пользователи им довольны.

А кто-то утверждал, что софт на WPF должен всегда недопустимо тормозить? Вроде, такого не было. Мы, в общем, как раз о том сегменте, где те самые проценты разницы в производительности программ на C++ и .Net (или не проценты — как повезёт) имеют значение.

ГВ>>Прости, а кто-то утверждал, что C++ — функциональный язык? Говорили, что он поддерживает функциональный стиль. Это несколько не одно и то же. Не надо додумывать, а потом спорить с додуманным.
C>Да не поддерживает он функциональный стиль. Хотите функциональный стиль — смотрите тот же F#.

Упс. А лямбды — не функциональный стиль? Да даже бустовые замыкания — и то функциональный стиль.

ГВ>>>>С кем-то я совсем недавно спорил по поводу читабельности... А, с Владом как раз. Давай, теперь с тобой. Что такое "читабельность"? Какова связь читабельности и, например, open/close principle?
C>>>Самая что ни есть прямая.
ГВ>>Сначала ответь на первый вопрос: что такое "читабельность"?
C>Cвойство текстового материала, характеризующее лёгкость восприятия его человеком.

Каковы объективные характеристики этого свойства (я и в самом деле этого не знаю, хоть пальцем ткни, где про сие почитать)? Какова связь этого свойства с open/close principle?

ГВ>>>>Вот те раз, а мужики-то и не знают, что "лёгкость понимания", оказывается, зависит от чистоты парадигмы.
C>>>Легкость понимания зависит от выразительности и лаконичности синтаксиса языка и структуры кода (и других менее значимых факторов). В этом плане С++, скажем прямо, сосет. И Ваша реализация IoC тому самое явное доказательство (для сравнения смотрите исходник Сastle MicroKernel).
ГВ>>Я разве утверждал, что C++ — лаконичный язык? Его относительная многословность — вполне медицинский факт.
C>"а мужики-то и не знают, что "лёгкость понимания", оказывается, зависит от чистоты парадигмы"

Это к чему? Я что-то запутался. Чтобы исключить намёки, повторю своё мнение. Итак, на мой взгляд, чистота парадигмы — неизвестно что, поскольку зачастую неизвестно, что такое сама парадигма (только на википедию ссылаться не надо); лёгкость понимания — явление субъективное, т.е. — с трудом поддающееся объективным измерениям (мне, например, вполне понятно, что написано в IoC.h и ещё в туче других библиотек на C++); "многословность" — до некоторой степени измерима сравнением количества лексем в коде аналогичной функциональности на разных языках.

Понятно, почему я иронизирую над апелляциями к "лёгкости понимания" и "чистоте парадигмы"?

ГВ>>Кстати, что касается IoC, то мы начали с желательной модели использования. И кстати, содержательных комментариев так пока и не последовало.
C>Глаза раззуйте.

Дружище, как-то оно не по-товарищески — хамить в ответ на предложенный код. Собери свои претензии в один постинг, будь добр, и забрось в ответ по IoC, а то я не могу понять, где претензии к предложенному примеру, где к C++, где к IoC-контейнерам на C++ "вообще" и т.п.

ГВ>>Меня это устраивало бы, потому что можно сделать высококачественный компилятор и спокойно его отшлифовать, не опасаясь очередного виража стандартизаторов. А не потому, что я нашёл тихую заводь.
C>Вы не ответили на поставленный вопрос: Какой процент разработчиков компилятора от общего числа программистов?

Это нерелевантный в данном контексте вопрос, да и не смог бы я на него содержательно ответить, даже если бы и захотел. С другой стороны, cие не имеет ни малейшего значения с точки зрения оценки самого C++. Пойми, медленное развитие C++ как языка имеет свои положительные стороны — как минимум, разработчики компиляторов могут дать более качественные (оптимизированные и т.п.) компиляторы, чем это было бы в ситуации очень быстрых изменений. Во всяком случае, такое предположение вполне логично.

Здравствуйте, criosray, Вы писали:

ГВ>>Ну дык, pococapsule и по объёму чуть не в 10 раз меньше, чем Castle Windsor. Что тут бочку-то катить?
C>Кого волнует объем?

В общем — никого, согласен. Просто pocoapsule — это мелочёвка, в общем-то. Годится в качестве заготовки, пожалуй, ну так она для того и приведена была здесь.

ГВ>>Тем не менее, в качестве ответа на вопрос об IoC — вполне себе ответ.
C>Нет, это не ответ. Что толку от такого IoC, если у него кроме самого базового DI и нету больше ничего?
C>Вот Вы лично пользуетесь PocoCapsule? Наверняка нет, а мы IoC используем на каждом шагу потому, что сильно облегчает жизнь и естественным образом улучшает архитектуру систем.

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

C>>>Где возможность задать Lifecycle?
C>>>Где возможность задать Lifestyle?
ГВ>>Это уже фичи, которые в тот или иной контейнер могут быть внесены или нет.
C>Ну покажите мне хоть один контейнер на С++, где были бы эти "фичи". Это, кстати, не просто фичи, а самая основа работы контейнера. Что мне толку от контейнера, если я не могу задать lifestyle компоненты?

Сдаётся мне, что тут дело в несколько иной общей культуре разработки на C++ — здесь не так модны большие тяжёлые компоненты типа "унифицирующих контейнеров" a-la Java. А написать самостоятельно что-то в таком духе — дело не сложное (как раз мой пример о том и свидетельствует). Можно и lifestyle/lifecycle прикрутить — опять таки, дело не хитрое.

C>>>Где автоматическая регистрация компонент по шаблону?
ГВ>>Можно сделать и так, но понадобится глобальный регистратор всех компонентов, используемых в такой операции.
C>Ну сделайте. Очень хочу посмотреть. Условия все те же: конфигурирование через конфиг файл. То есть указывается сборки и шаблон, по которому ее сканировать и дальше все делается автоматически контейнером.

Нет такого явления в C++, как "сборки" — это раз. Есть DLL, но нет такого явления, как "сканирование содержимого DLL". Чтобы получить нечто подобное поиску нужного класса нужно а) определить способ и формат описания класса (реестр), б) занести описания всех классов в такой реестр и в) напустить на указанный реестр операцию поиска. В рантайме-то у C++-ных классов никаких имён нет. Техника очевидная для любого C++-ника. В принципе, если формат выбран с человекочитаемыми именами, то их можно перенсти и в конфиг-файл. Тоже, в общем, не бином Ньютона.

Мне сейчас, честно говоря, просто возиться с этим не хочется. Для форумного спора как-то слишком много усилий на квадратный дюйм.

C>>>Где расширяемость аналогичная Сastle Facilities?
ГВ>>Да тоже, вроде бы, ничего сверхъестественного.
C>Ну нету ведь?

Где? У меня?

C>>>Где интерцепторы???
ГВ>>Вот с этим сложнее, но и то, из-за кодогенерации.
C>Конечно посложнее. И судя по тому, что готовых рабочих решений нету — невыполнимая задача для С++. Так?

Проще сказать — да, невыполнимая. Прокси придётся писать вручную. Максимум, чем можно воспользоваться — довольно хитрыми играми с препроцессором.

---

ГВ>>Ты всё же определись, чего ты хочешь от собеседников: чтобы сделали копию Castle Windsor или MS Unity, продемонстрировали возможный подход или ещё чего-то?
C>Да, я хочу чтоб мне показали аналог Виндсор, но для С++. Еще я хочу увидеть аналог RhinoMocks.

Зачем? Это послужит тебе аргументом за то, что C++ — "достаточно мощный"? Или интересует принципиальная возможность реализации таких вещей?

ГВ>>Я надеюсь — ты не просто ищешь повод фыркнуть погромче, верно? Можно написать IoC-контейнер и конфигурируемый, и гибкий, и с обилием других качеств, но это, в общем, довольно объёмная работа. Тот же Castle Windsor, если судить по объёму исходников, ну никак не один и не два человеко-месяца.
C>Для справки, на дотнет реализаций этих контейнеров уже больше десятка (а то и двух десятков). Почему на вашем столь любом замечательном мощном С++ до сих пор нету ничего подобного? Можете ответить на этот вопрос?

Значит, просто никому не нужно. А вообще говоря, не знаю, почему оно так.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Как ты правильно заметил, Тьюринг-полные языки, в общем, эквивалентны по своим возможностям в смысле выражения абстракций. Всё дело в итоговой цене на билет. Я не сомневаюсь, что абстракцию автоматического управления ресурсами вроде std::auto_ptr можно реализовать и на Хаскеле, и на Лиспе и ещё много на чём. Вопрос остаётся тем же самым: сколько это будет стоить пользователю.

У тебя проблемы с терминологией. std::auto_ptr — это помошник упрощающий ручное управление памятью. В языках с автоматическим управлением памятью они ненужны. Меж тем сделать их не сложно.

ГВ>Так с современными, или с теми, которые старше и на которых обкатывались идеи, впитанные C++?

А что мешает языку быть старше другого языка и оставаться при этом современным? Лисп вещь самодостаточная. У него никогда не было проблем с std::auto_ptr. По этому он и сейчас почти в любой пенесометрии порвет С++ как тузик грелку.

ГВ>В новой версии стандарта — поддерживает.

1. Где эта версия? Стандарт уже зарелизили? А то мне про него последние 10 лет рассказывают, рассказывают...
2. Без GC толку от этого будет не много.

VD>>Еще одно утверждение не достойное серьезного человека. Рабивается простым примером. По верх дотнета реализован С++ в котром возоности шаблонов реализованы полностью.

ГВ>По всей видимости, ollv имеет в виду C#, говоря о .Net.

Ну, так пора запомнить, что это разные вещи.

ГВ>В том же, что кодогенерация C++ перенастроена на IL ничего необычного нет.

Спасибо за поддержку.

ГВ>Тьюринг-полнота, ага. Из C++ можно и Lisp генерировать. И наоборот. Вопрос в практичности такого решения.

А что непрактичного в генерации il-а? Скорсть практически та же. Другое дело, что многим это может быть не нужно. Но перенацеливание С++ для дотнета было сделано ради упрощения итеропа, так что практичность и целесообразность очень высоки.

VD>>Теперь я тебе открою правду о шаблонах.

ГВ>[skip обнажённая правда, от блеска которой слепит глаза и хочется сморкаться]

Это у тебя неадекватные реакции. Ничего, бывает....

ГВ>Всё это, конечно, правильно, хоть и с некоторыми поправками. Но поправки сейчас не суть важны. Важно другое: что та самая "область" в которой царят все за компанию (кроме C++) магическим образом не пересекается с теми областями, в которых от C++ никак не могут (и не хотят) избавиться по сугубо практическим соображениям.

Ошибаешься! Такие как ollv по незнанию или из фанатических побуждений применяют С++ там где ему совсем не место и в условиях где он противопоказан.

Понимаешь, я не буду спорить, что если задача очень тиражная и скорость является основным требованием, то С++ подходящий язык. Хотя и тут есть альтернативные решения и С++ зачастую выбирается исходя из распространенности и разрекламированности. Но когда сил не много, а нужно в кратчайшие строки получить надежное решение, когда денег на разработку нехватает, С++ является худшим выбором. Например, на С++ сайты не пишут даже в Майкрософт и АйБиЭм. А наши лаботрясы пишут. И еще с пеной у рта доказывают, что только так и надо.

ГВ>То есть, она как бы есть, но её значимость как бы слегка эфемерна по отношению к тому набору требований, с которым приходится иметь дело C++-никам.

В большинстве случаев это домысли тех самых С++-ников.

ГВ>А так — да, бесспорно. На Lisp можно написать очень много всего интересного. Если бы ещё не потеря производительности по сравнению с "убогим" C/C++ — всё было бы совсем хорошо.

Когда-то давно производительность Лиспа была огромной проблемой. Но сейчас есть высокопроизводительные компиляторы. Плюс Лисп позволят генерировать исполянемый код. Вот недавно мне дали ссылку на забавный продукт (можно сказать в некотором роде конкурент Немерла):
http://lambda-the-ultimate.org/node/3281
Это язык основанный на Лиспе позволяющий расширять свой синтаксис и семантику. К сожалению, информации по нему пока очень мало. Но факт в том, что этот язык имеет библиотеку позволяющую преобразовывать код на этом языке в il тем самым уходя от интерпретации и получая высокопроизводительные решения.

ГВ>Суть вещей — многогранное явление. Для каждого она своя.

Для людей не обладающих информацией она всегда однобока.

O>>> Кроме того, на плюсах вполне реализуемы элементы не родственных стурктур, к примеру итерации for_each, find_if count_if, функторы, придают плюсам оттенки функциональных языков,

VD>> Они придают плюсам оттенок помойки. Попиши сначала на полноценном ФЯ, а потом делай такие заявления.

ГВ>Помойка или нет — это сугубо эмоциональная оценка.

Эмоциональная она для тех, кто не видел библиотек функциональных языков. Там все очень смеялись бы увидев функции вроде find_if и count_if. Их авторам рассказали бы, что на то есть универсальные функции высшего порядка filter и fold, а find_if и count_if реализуются на их базе добавлением простейшей лямбды.

ГВ>Не нравится — не пользуйся, никто не заставляет.

Не нравится. Не пользуюсь. Будь уверен.

ГВ> Зато нет никакой необходимости любой ценой приводить структуру потока управления в соответствие с некоторой "правильной парадигмой".

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

VD>>[...] С++ тут откровенный лузер, если сравнивать его с такими языками, реализованными поверх дотнета, как Nemerle и Lisp. Вот где МП доведено до высшего пилотажа. Причем оно исходно предусмотрено в языка, а не достигается использованием побочных эффектов системы типов.

ГВ>Забавно, что как раз использование "побочных эффектов" и делает C++ столь привлекательным по критерию производительности программиста при сохранении производительности продукта.

Забавно, что ты даже не понимаешь о чем идет речь. Речь же идет о побочных эффектах воплощения шаблонов. Эти эффекты позволяют заниматься метапрограммированием во время компиляции. Но как и все, что достигается не предусмотренными для этого средствами, данное решение является очень неудобным и ограниченным.

ГВ>А чистота "метапрограммирования", или "функционального программирования", или ещё какая "чистота" какой-нибудь очередной мутной "парадигмы" вообще не шибко-то кого и беспокоит (в мире C++). Пуризм — это ещё одно ругательство, как и BASIC, если ты не в курсе. Есть только два критерия: "удобно написать удобную фишку X" и "иметь возможности для отступления в случае потерь производительности".

Это как раз тот случай где отсутствие чистых и грамотных решений толкает на использование кривых.
Ты с книгами Александеску хорошо знаком?

ГВ>Теоретические же базисы хороши для формирования общей культуры программиста и исследования теоретических же проблем. Хотя это отнюдь не отрицает, например, того, что Lisp хорош в сфере обработки символических данных. Кстати, обрати внимание — Lisp тоже поддерживает императивный стиль одновременно с функциональным.

Да, да, да. Зачем наука в программировании? Ты давно всем доказал, что программирование особая отрасль и мозг в ней не нужен. Главное трясти по сильнее. То ли дело автомобили. Вот там наука важна. Ведь на автомобилях ездеем мы сами, а софт используют какие-то ламеры.

Здравствуйте, VladD2, Вы писали:

VD>У тебя проблемы с терминологией. std::auto_ptr — это помошник упрощающий ручное управление памятью. В языках с автоматическим управлением памятью они ненужны. Меж тем сделать их не сложно.

GC научился удалять строго указанные объекты (освобождать занятую память) в строго указанный момент времени? Он же, вроде, с точностью до поколения может работать?

ГВ>>Так с современными, или с теми, которые старше и на которых обкатывались идеи, впитанные C++?
VD>А что мешает языку быть старше другого языка и оставаться при этом современным? Лисп вещь самодостаточная. У него никогда не было проблем с std::auto_ptr. По этому он и сейчас почти в любой пенесометрии порвет С++ как тузик грелку.

ГВ>>В новой версии стандарта — поддерживает.
VD>1. Где эта версия? Стандарт уже зарелизили? А то мне про него последние 10 лет рассказывают, рассказывают...

Ну... Комитет (tm).

VD>2. Без GC толку от этого будет не много.

ИМХО, ты ошибаешься.

ГВ>>В том же, что кодогенерация C++ перенастроена на IL ничего необычного нет.
VD>Спасибо за поддержку.

Пожалуйста.

ГВ>>Тьюринг-полнота, ага. Из C++ можно и Lisp генерировать. И наоборот. Вопрос в практичности такого решения.
VD>А что непрактичного в генерации il-а? Скорсть практически та же. Другое дело, что многим это может быть не нужно. Но перенацеливание С++ для дотнета было сделано ради упрощения итеропа, так что практичность и целесообразность очень высоки.

Я и не оспариваю практическую полезность генерации IL компилятором C++.

ГВ>>Всё это, конечно, правильно, хоть и с некоторыми поправками. Но поправки сейчас не суть важны. Важно другое: что та самая "область" в которой царят все за компанию (кроме C++) магическим образом не пересекается с теми областями, в которых от C++ никак не могут (и не хотят) избавиться по сугубо практическим соображениям.
VD>Ошибаешься! Такие как ollv по незнанию или из фанатических побуждений применяют С++ там где ему совсем не место и в условиях где он противопоказан.

Это слишком сильное утверждение, насчёт незнания и фанатизма. Так что, тут я согласиться не могу.

VD>Понимаешь, я не буду спорить, что если задача очень тиражная и скорость является основным требованием, то С++ подходящий язык. Хотя и тут есть альтернативные решения и С++ зачастую выбирается исходя из распространенности и разрекламированности. Но когда сил не много, а нужно в кратчайшие строки получить надежное решение, когда денег на разработку нехватает, С++ является худшим выбором. Например, на С++ сайты не пишут даже в Майкрософт и АйБиЭм. А наши лаботрясы пишут. И еще с пеной у рта доказывают, что только так и надо.

Не надо переворачивать с ног на голову. Сайты бывают разные, и требования — тоже разные. MS и IBM (как и все остальные) вольны поступать так, как им заблагорассудится. И кроме всего прочего, слишком мало критериев для отсечения C++: "в кратчайшие строки получить надежное решение, когда денег на разработку нехватает". Он запросто может оказаться наилучшим выбором с учётом других факторов. Тут проблема в другом: почему-то те, кто ругают C++ приписывают ему какую-то имманентную глюкавость, запредельную трудоёмкость и т.п. чуть ли не по всем аспектам, тогда как на самом деле это а) не так и б) зачастую обусловлено тем же контекстом, т.е. постановкой задачи, анализом требований и т.п.

ГВ>>То есть, она как бы есть, но её значимость как бы слегка эфемерна по отношению к тому набору требований, с которым приходится иметь дело C++-никам.
VD>В большинстве случаев это домысли тех самых С++-ников.

Домыслы — это как раз попытка любой ценой соблюсти теоретическую цельность. ИМХО, бессмысленная и глупая затея: простое заколачивание гвоздя может быть обложено целой тучей теорий и псевдотеорий, но заколачивальщик вовсе не обязан им следовать.

ГВ>>А так — да, бесспорно. На Lisp можно написать очень много всего интересного. Если бы ещё не потеря производительности по сравнению с "убогим" C/C++ — всё было бы совсем хорошо.
VD>Когда-то давно производительность Лиспа была огромной проблемой. Но сейчас есть высокопроизводительные компиляторы.

AFAIK, на данный момент Lisp примерно на 5-20% проигрывает C++, пробегало где-то на www.franz.com. Естественно, это не весь Lisp, вполне вероятно, что есть и пошустрее. Про SBCL я знаю, но сильно с ним не возился.

VD>Плюс Лисп позволят генерировать исполянемый код. Вот недавно мне дали ссылку на забавный продукт (можно сказать в некотором роде конкурент Немерла):
VD>http://lambda-the-ultimate.org/node/3281
VD>Это язык основанный на Лиспе позволяющий расширять свой синтаксис и семантику. К сожалению, информации по нему пока очень мало. Но факт в том, что этот язык имеет библиотеку позволяющую преобразовывать код на этом языке в il тем самым уходя от интерпретации и получая высокопроизводительные решения.

Тоже неплохо.

ГВ>>Суть вещей — многогранное явление. Для каждого она своя.
VD>Для людей не обладающих информацией она всегда однобока.



VD>>> Они придают плюсам оттенок помойки. Попиши сначала на полноценном ФЯ, а потом делай такие заявления.
ГВ>>Помойка или нет — это сугубо эмоциональная оценка.
VD>Эмоциональная она для тех, кто не видел библиотек функциональных языков. Там все очень смеялись бы увидев функции вроде find_if и count_if. Их авторам рассказали бы, что на то есть универсальные функции высшего порядка filter и fold, а find_if и count_if реализуются на их базе добавлением простейшей лямбды.

Да нет, она эмоциональная по сугубо формальным признакам. find_if и Co вполне решают свои задачи в рамках STL/C++. Понятно, что это не filter/fold, но тем не менее.

ГВ>> Зато нет никакой необходимости любой ценой приводить структуру потока управления в соответствие с некоторой "правильной парадигмой".
VD>Это ты в том смысле сказал, что усе уже сделано не правильно и делать что-то правильно не надо?

Да не... Парадигм слишком много и каждая — самонаилучшая. С точки зрения адептов. Но абсолютная "правильность" — это миф такой, весьма живучий, вроде абсолютной качественности. Есть решения подходящие более или менее по вполне определённым критериям, вот и всё. Эти критерии выбираются исходя из требований текущих и прогнозируемых. Иногда удаётся предугадать изменение требований и тогда решение объявляется "правильным", иногда — нет и его объявляют "неправильным". Ну и ещё добавим сюда критерии, связанные с практическим удобством разработки и легко прогнозируемыми модификациями.

ГВ>>Забавно, что как раз использование "побочных эффектов" и делает C++ столь привлекательным по критерию производительности программиста при сохранении производительности продукта.
VD>Забавно, что ты даже не понимаешь о чем идет речь. Речь же идет о побочных эффектах воплощения шаблонов. Эти эффекты позволяют заниматься метапрограммированием во время компиляции. Но как и все, что достигается не предусмотренными для этого средствами, данное решение является очень неудобным и ограниченным.

Удивительно, но именно шаблоны я и имел в виду.

ГВ>>А чистота "метапрограммирования", или "функционального программирования", или ещё какая "чистота" какой-нибудь очередной мутной "парадигмы" вообще не шибко-то кого и беспокоит (в мире C++). Пуризм — это ещё одно ругательство, как и BASIC, если ты не в курсе. Есть только два критерия: "удобно написать удобную фишку X" и "иметь возможности для отступления в случае потерь производительности".
VD>Это как раз тот случай где отсутствие чистых и грамотных решений толкает на использование кривых.

Скажем так, это квинтэссенция практических мотиваций.

VD>Ты с книгами Александеску хорошо знаком?

Наизусть не помню, конечно. А что?

ГВ>>Теоретические же базисы хороши для формирования общей культуры программиста и исследования теоретических же проблем. Хотя это отнюдь не отрицает, например, того, что Lisp хорош в сфере обработки символических данных. Кстати, обрати внимание — Lisp тоже поддерживает императивный стиль одновременно с функциональным.
VD>Да, да, да. Зачем наука в программировании? Ты давно всем доказал, что программирование особая отрасль и мозг в ней не нужен. Главное трясти по сильнее. То ли дело автомобили. Вот там наука важна. Ведь на автомобилях ездеем мы сами, а софт используют какие-то ламеры.

Да ну?! Вроде как я обычно доказываю прямо противоположное. Мозг как раз нужен и теоретическая подготовка — тоже. Так что, что-то ты перепутал.

Здравствуйте, Геннадий Васильев, Вы писали:

VD>>У тебя проблемы с терминологией. std::auto_ptr — это помощник упрощающий ручное управление памятью. В языках с автоматическим управлением памятью они ненужны. Меж тем сделать их не сложно.

ГВ>GC научился удалять строго указанные объекты (освобождать занятую память) в строго указанный момент времени? Он же, вроде, с точностью до поколения может работать?

GC бывают разные, но их объединяет одно — при наличии GC не надо управлять жизнью объектов вручную.

ГВ>>>В новой версии стандарта — поддерживает.
VD>>1. Где эта версия? Стандарт уже зарелизили? А то мне про него последние 10 лет рассказывают, рассказывают...

ГВ>Ну... Комитет (tm).

Ага. Комитет — это жизненная форма, наделённая шестью или более ногами, и лишенная мозга. (с) Роберт Хайнлайн. Потому и развитие С++ такое бурное.

VD>>2. Без GC толку от этого будет не много.

ГВ>ИМХО, ты ошибаешься.

Да? Объясни тогда оду простую вещь. Для эффективного использования замыканий сами замыкания и все на что они замкнуты (т.е. имеют ссылки) должно жить столько сколько живет само замыкание. А замыкание может быть передано в ФВП которая так же может передать его в другие ФВП. Как не имея системы автоматического управления памятью реализовать безопасные (не приводящие к UB ошибкам времени выполения) замыкания?

VD>>Ошибаешься! Такие как ollv по незнанию или из фанатических побуждений применяют С++ там где ему совсем не место и в условиях где он противопоказан.

ГВ>Это слишком сильное утверждение, насчёт незнания и фанатизма. Так что, тут я согласиться не могу.

Что в нем сильного? Оно не противоречит утверждению, что есть люди использующие С++ осознанно и для задач где он является конкурентно-способным.

ГВ>Не надо переворачивать с ног на голову. Сайты бывают разные, и требования — тоже разные.

Ага. Не надо. Не надо разглагольствовать о разных задах сайтов. С++ там по любому не место. Если только в виде какого-то там драйвера или мелкого компонента вроде ISAPI-фильтра.

ГВ>MS и IBM (как и все остальные) вольны поступать так, как им заблагорассудится.

Ага. И выбирают для сайтов Яву и дотнет.

ГВ> И кроме всего прочего, слишком мало критериев для отсечения C++: "в кратчайшие строки получить надежное решение, когда денег на разработку нехватает". Он запросто может оказаться наилучшим выбором с учётом других факторов.

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

ГВ> Тут проблема в другом: почему-то те, кто ругают C++ приписывают ему какую-то имманентную глюкавость, запредельную трудоёмкость и т.п. чуть ли не по всем аспектам, тогда как на самом деле это а) не так и б) зачастую обусловлено тем же контекстом, т.е. постановкой задачи, анализом требований и т.п.

Глюкавость приписывают не языку, а коду на нем написанном. И не почему-то, а исходя из общирного опыта и объективных логических рассуждений. Язык не типобезопасен, возлагает на программиста массу ответственности.
Есть такое умное высказывание (не помню чье) — человек не должен делать работу которую может сделать машина. А С++ заставляет человека делать работу которую можно возложить на машину. Все остальное последсвия. Ну, и С++ как раз очень сильно сковывает программиста в выборе абстракции. По сути, большинство С++-программистов, начинают решать все задачи с помощью шаблонов. Причем очень распростронено мнение, что производительность важнее качества.

Многие защитники С++ приводят в качестве примера 3D-игры. Мол, "почему их пишут на С++?". А стоило бы посмотреть на другой аспект. Почти все эти игры безбожно глючат. Играть в некоторые до выхода патчей просто невозможно. Большая часть ошибок в этих играх могла бы быть попросту не допущена, будь программа написана на более качественном языке.

ГВ>>>А так — да, бесспорно. На Lisp можно написать очень много всего интересного. Если бы ещё не потеря производительности по сравнению с "убогим" C/C++ — всё было бы совсем хорошо.
VD>>Когда-то давно производительность Лиспа была огромной проблемой. Но сейчас есть высокопроизводительные компиляторы.

ГВ>AFAIK, на данный момент Lisp примерно на 5-20% проигрывает C++, пробегало где-то на www.franz.com.

Твой AFAIK. Высосан из пальцев. В прочем я не Лиспер и дать тебе точных данных не могу. Но я проверял их данные и скорее соглашусь с ними, а не с тобой. Кстати, проигрышь в 20% это вообще смешно. Отдельные компиляторы С++ проигрывают друг-другу в разны на разных задачах.

В прочем можно посмотреть здесь.

ГВ>Про SBCL я знаю, но сильно с ним не возился.

Я его пробовал. Очень быстрый, но глюкавый и не очень стандартный. Главная проблема в том, что для Винды его делают в последнюю очередь. Верся для Винды значительно отстает. Но для пенисометрии идеален. На многих тестах рвет С++-ные компиляторы как тузик грелку.

ГВ>Тоже неплохо.

Еще как не плохо. И это технологии про которые уже забыл. А ведь им 50 лет!

ГВ>Да нет, она эмоциональная по сугубо формальным признакам. find_if и Co вполне решают свои задачи в рамках STL/C++. Понятно, что это не filter/fold, но тем не менее.

Офтоп — Люблю русский "да нет".
Если понятно, то лучше помалкивать про find_if и компанию. И уж точно не заикаться о "применимости к объектам разного класса" или как там?...

ГВ>>>Забавно, что как раз использование "побочных эффектов" и делает C++ столь привлекательным по критерию производительности программиста при сохранении производительности продукта.
VD>>Забавно, что ты даже не понимаешь о чем идет речь. Речь же идет о побочных эффектах воплощения шаблонов. Эти эффекты позволяют заниматься метапрограммированием во время компиляции. Но как и все, что достигается не предусмотренными для этого средствами, данное решение является очень неудобным и ограниченным.

ГВ>Удивительно, но именно шаблоны я и имел в виду.

Да? Иди прочти еще раз свои слова. Если ты говорил о шаблонах, то они вообще теряют смысл.

ГВ>>>А чистота "метапрограммирования", или "функционального программирования", или ещё какая "чистота" какой-нибудь очередной мутной "парадигмы" вообще не шибко-то кого и беспокоит (в мире C++). Пуризм — это ещё одно ругательство, как и BASIC, если ты не в курсе. Есть только два критерия: "удобно написать удобную фишку X" и "иметь возможности для отступления в случае потерь производительности".
VD>>Это как раз тот случай где отсутствие чистых и грамотных решений толкает на использование кривых.

ГВ> Скажем так, это квинтэссенция практических мотиваций.

Это э....ыы... жопа, если одним словмо.

VD>>Ты с книгами Александеску хорошо знаком?

ГВ>Наизусть не помню, конечно. А что?

Но знаком? А с метапрограммированием в Лисп или Немерле ты знаком?
Если знаком, то должен понимать, что это как небо и земля. В случае шаблонов С++ трудоемкость офигительная, сложность высокая, результат так себе и при этом все еще совсем плохо по ресурсам потребляемым компилятором. А в результате метапрограмма деже не может выдать сообщение об ошибке или обратиться к внешнему файлу. Ну, куда это годится?

VD>>Да, да, да. Зачем наука в программировании? Ты давно всем доказал, что программирование особая отрасль и мозг в ней не нужен. Главное трясти по сильнее. То ли дело автомобили. Вот там наука важна. Ведь на автомобилях ездеем мы сами, а софт используют какие-то ламеры.

ГВ>Да ну?! Вроде как я обычно доказываю прямо противоположное. Мозг как раз нужен и теоретическая подготовка — тоже. Так что, что-то ты перепутал.

Я перепутал? Ну, не знаю. Я тебя читал.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Упс. А лямбды — не функциональный стиль? Да даже бустовые замыкания — и то функциональный стиль.

В boost-е нет полноценных замыканий. Там очень ограниченная эмуляция.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Это нерелевантный в данном контексте вопрос, да и не смог бы я на него содержательно ответить, даже если бы и захотел. С другой стороны, cие не имеет ни малейшего значения с точки зрения оценки самого C++. Пойми, медленное развитие C++ как языка имеет свои положительные стороны — как минимум, разработчики компиляторов могут дать более качественные (оптимизированные и т.п.) компиляторы, чем это было бы в ситуации очень быстрых изменений. Во всяком случае, такое предположение вполне логично.

Качество компиляторов можно повысить спроектировав качественный язык, а не давая 10 лет на реализацию запутанного и мутного монстра.