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

K>>Нет, не реализуются. Без метапрограммирования никаких шаблонов проектирования в коде нет — только результат их применения в голове программиста. Поэтому к уровню кода они никакого значения не имеют.
_>Т.е. например в C# или Java шаблонов проектирования не существует? )))

Нет, не существует. Вы вообще-то процитировали ответ на ваш вопрос — см.выше.

_>Это можно сказать про любое приложение в функциональном стиле. А я спрашивал про конкретное.

Конкретно в текстовом редакторе:
Rope в котором хранится редактируемый текст. Дерево — монада, порядок текстовых блоков — моноид.
Лейаут виджетов — моноид.
Последовательность нажатий на клавиши — функтор.
Ширина окна — аппликативный функтор.
Сериализатор/десериализатор файла настроек — аппликативный функтор.
Парсер для подсветки кода — монада.
IOC-контейнер — монада.
и т.д.

K>>Ну конечно, если брать какую-нибудь убогую библиотеку, да еще и специально писать ужасы — тогда конечно.
_>Т.е. стандартная библиотека Хаскеля убогая? ) Понятно... )))

Вы даже не представляете всю убогость стандартной библиотеки хаскеля — она поражает воображение! Это если считать стандартной библиотекой то, что в репорте описано. Та часть библиотеки array, которую вы использовали ни в каких стандартах не описана, кстати. Более того, на стандартизированном подмножестве хаскеля она даже нереализуема.
Если же считать стандартом де факто набор библиотек из haskell-platform то и используемая мной (vector) и вами (array) библиотеки стандартные, просто array морально устарела за годы до того, как код, на C++ который вы тут приводите, стал стандартизированным.

_>А какая у нас нормальная? )

vector

_>Ооооо, снова наша таинственная польза от системы контроля эффектов. Которая много раз заявлялась, но ни разу не демонстрировалась... Нуну)))

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

_>Уже хорошо.

Я тут это написал еще до того, как начал с вами обсуждать ужасы "монадного кода".

_>Только в C++ версии нет ни единого оператора/вызова функции не по делу.

Разумеется есть. Например cbegin() и cend().

_>А в Haskell версии (даже с помощью "нормальной" библиотеки), которая вроде как должна быть вообще без мусора, мы имеем "всего лишь" fmap, V.unsafeFreeze, V.thaw, которые вообще непонятно чем заняты по отношению к прямой функциональности нашего кода.

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

_>И это если забыть про вынужденно кривой код модификации самого массива.

В чем же его "вынужденная кривизна"?