[C++?] Серьезный вопрос.

> Судя по аргументации в стиле: "А там надо память вручную освобождать" --, местные "ниасиляторы" не продвинулись дальше cout << "Hello, world" << endl.

То от буста с локи отговариваешь, то пхыкаешь на cout << "Hello, world" << endl... Непоследовательненько....

> Кармак?

Лучше.

>>Вместо того чтобы просто описать поле объекта я должен еще обеспечить фан вида getXXX() const/setXXX().

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

Во всех языках кроме С++ как-то обходятся.

> Срочно закапывайте петун за global interpreter lock. Кстати, заодно и перл можно. В нем ведь тоже как-то кривовато с потоками. Да и C можно закопать, в принципе: в стандарте ни слова о потоках.

Он начинает что-то понимать? 8)))

>Покупаешь full suspension bike, броню, едешь в горы

я без брони катаюсь, броню придумали трусы ! %) (после бурного детства проведенного в хибинах на горных лыжах)

>>б) И вообще, смарт-указатели - говно.

>Слова убежденного ниасилятора.

Влом писать много букав, но напишу. Дело в том, что есть только три способа реализовать смарт-указатель: деструктивное копирование как в std::auto_ptr, клонирование и подсчет ссылок. Первое и второе не обеспечивают того поведения которое ожидают от указателя и поэтому нарушают принцип "наименьшего сюрприза", а третье является единственным доступным решением и поэтому с одной стороны не обеспечивает гибкость а с другой запутывает язык из-за тонны реализаций. Итого - говно, ЧТД.

>Кстати, а давайте вспомним, какие костыли в языках с GC для контроля жизни объектов. Навскидку вспоминается finally в Java, множественные костыли и IDisposable в C#. Чего только не напридумывают. А всего-то требовалось следить за тем, чтобы каждому malloc соответствовал free на выходе.

Доо, давай раздувай прыщик на попе до масштабов рака 4-й степени.

>>Во-первых начнем с того что стандартного С++ под чистый ДОС нет.

>Ах извини, что в 1991 году ничего не знали о стандарте C++, который примут в 1998.

Перестань вилять. В win16 применялись парадигмы несовместимые с С++ вообще. В частности, там были хендлы вместо указателей, поэтому в динамической памяти можно было размещать только POD-объекты.

>Да и STL тогда был весьма зачаточный.

std::vector<>::near_iterator, std::vector<>::far_iterator. Да, я могу себе это представить.

>В win16 применялись парадигмы несовместимые с С++ вообще.

И какие же?

>В частности, там были хендлы вместо указателей, поэтому в динамической памяти можно было размещать только POD-объекты.

И таки нельзя было писать base_class *instance = new my_class_with_virtual_functions(some_arg)? Не верю.

>std::vector<>::near_iterator, std::vector<>::far_iterator.

Палишься! Парой сообщений выше ты устверждал, что неймспейсов в bc++ не было. Или они таки были?

>нарушают принцип "наименьшего сюрприза"

Ах да, один из главнейших принципов ниасиляторов: "Я не осилил, потому что конструкция X делает не то, что я от нее ожидаю, а что-то странное, описанное в мануалах, которые я не читаю, ибо принципиальный Ъ ниасилятор",

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

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

>Итого - говно

Итого мосье просто банально не смог вникнуть в суть принципа RAII. Правда меня по-прежнему удивляет, как же это ты не вопишь по поводу ручного (!) управления файловыми дескрипторами, соединениями с БД и прочими ресурсами, которые за тебя GC не разгребет?

[troll] А что вы вообще сретесь то, чета я нить потерял.

Ведь языки не просто так от нехер делать выдумывают, а для каких то своих целей, например тут кто-то говорил что ерланг говно, а на нем наскока я читал запросто так можно 10к потоков организовать, вот вроде как во франции метро на нем работает. На хаскеле наскока я знаю писали прототипы pugs. А на какой нить там аде наверное беспилотники летают бомбить афганистан и еще че-нить, и ядерным оружием рулят. А вы всё зациклились на офисах как будто больше ниче не программируют. Да нахер он ваще кому нужен этот ваш офис, ниче все равно хорошего не изобрели со времен ворд перфекта и слово и дело, которые работали на ibm xt c 4мегагерцовым 86 %-)

Чисто вот начинает доставлять тред где одни "умные" дяди доказывают "другим" умным дядям о превосходстве теплого над мягким %)

[/troll]

Ты теги перепутал. В начале должно стоять [/troll], в конце -- [troll]. 8))

да, а на глобальном и надежном php настоящие гуру пишут высокомасштабируемые вверх и вширь промышленные ынтырпрайз системы, вот ! %-) А вы все о си. Тоже мне, подумаешь, кроссассемблер ! %)

Угу. Ты так считаешь? Полагаю, что даже в свете GPL'изации, для контроля было бы не дурственно произвести вполне кафолический auto de fe в отношении сего поделия. Невзирая даже на то, что нокия сейчас нацелилась в maemo перетянуть. Прикольненько так... Все думали что GTK+ это "альфа и омега" маемо... Ан нет.

Впрочем, весь сей спор по сути дела, можно свести к попытке ответить на вопрос -- кошерно аль нет предоставлять ПРОГРАММИСТУ удобство записи алгоритма. Ибо самому по себе алгоритму совершенно пох как он там записан. Главное чтоб логико-семантических ошибок не содержал.

Трансляция в маш. код алгоритма то же мало кого скребёт. Ибо в противном случае "программистов на дельпи" не было бы вовсе.

Ну, других побудительных причин для спора не вижу. Впрочем, Бог бы с ним... Есть тема малость посмеяться и то хлеб...

>>нарушают принцип "наименьшего сюрприза"

>Ах да, один из главнейших принципов ниасиляторов: "Я не осилил, потому что конструкция X делает не то, что я от нее ожидаю, а что-то странное, описанное в мануалах

Смарт-указатель должен вести себя как обычный указатель, то есть, в частности, обеспечивать семантику копирования как у указателя. Такие дела. BTW, auto_ptr уже объявили "злом" и задепрекейтили в новом стандарте. А клонирование либо фрагментирует память либо требует O(N) для поиска подходящего чанка при каждом копировании, если закрыть глаза на то что клонирующий смарт-указатель не ведет себя как указатель.

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

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

Я ставил вопрос иначе: нафига класть на плечи программиста проблему которую можно решить только одним способом?

>Это же ерунда по сравнению с тем, сколько калорий тебе бы пришлось потратить на придумывания способа "как избежать циклической зависимости".

А зачем ее избегать? Если она нужна то она нужна.

>Правда меня по-прежнему удивляет, как же это ты не вопишь по поводу ручного (!) управления файловыми дескрипторами, соединениями с БД и прочими ресурсами, которые за тебя GC не разгребет?

Гнилой аргумент. Я его сам использовал когда был плюсофилом. По сравнению с управлением памятью это не проблема вообще.

>Итого мосье просто банально не смог вникнуть в суть принципа RAII.

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

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

Кривые руки детектед. Для справки: циклические ссылки почти наверняка указывают на плохой дизайн.

>И вообще, смарт-указатели - говно.

Говно - это сборщик мусора.

>Ну да, С++ вынуждает передавать объект в объект по const-ссылке чтобы избежать копирования.

Позволяет, а не вынуждает.

>Вместо того чтобы просто описать поле объекта я должен еще обеспечить фан вида getXXX() const/setXXX().

Это ты о пропертях мечтаешь? Хаха. К сведению, геттеры и сеттеры составляют менее половины от общего числа методов в обычной программе на c++.

> Это ты о пропертях мечтаешь?

Не знаю, о чём там мечтает автор, а я об АТД мечтаю...

> К сведению, геттеры и сеттеры составляют менее половины от общего числа методов в обычной программе на c++.

Это повод радоваться? По-моему, печалиться надо, что оно составляет кол-во процентов, сравнимое с 50.

> Да и C можно закопать, в принципе: в стандарте ни слова о потоках.

Ась? Чёсь? О каааак! А чё, POSIX 1003.4 ужо отменили штоль? Иль нет?

АО такие АО... С каких пор POSIX -- стандарт языка С?

АО такие АО..

> С каких пор POSIX -- стандарт языка С?

Вообще-то ни с каких.

Пожалуй, продолжу тему образования господина kemm'а в данном вопросе.

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

Однако, исходя из того, что сам по себе API POSIX-compat. системы как правило удовлетворяет в той или иной степени POSIX 1003.1 (ISO/IEC 9945), а там как ни крути, а С прописан, то... То весьма странно ожидать от IEEE ориентации на хаскель окамловый при определении чего либо. Начиная от расширений реального времени и заканчивая прочими интерфейсами системы. Впрочем, "странно" это было бы для меня сирого и убогого... Чего от кого ждать я и не знаю... =)))))))) Но ни чего хорошего. Это точно. =)))

>А клонирование либо фрагментирует память либо требует O(N) для поиска подходящего чанка при каждом копировании, если закрыть глаза на то что клонирующий смарт-указатель не ведет себя как указатель.

Во-первых, о каком N идет речь?

Во-вторых, ходят слухи, что "первый подходящий" ведет к меньшей фрагментации, чем "лучший подходящий". Кстати, в glibc malloc используется как раз "первый подходящий".

В-третьих, смешно читать рассуждения об O(N) от сторонника сборщика мусора, где цена O(const) ой как велика.

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

И, наконец, есть очень эффективные способы избежать фрагментации кучи и одновременно достичь скорости выделения O(const) для временных объектов. Так называемые "пулы". Но, похоже, ты о них не слышал или не использовал.

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

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

Объясни мне принципиальную разницу между ручным вызовом malloc/free и open/close.

>RAII это топорный сахар для сишного подхода "освобождаем ресурс на том же уровне где его аллоцировали".

Во-первых, такого "сишного подхода" просто не существует в природе.

Во-вторых, у тебя по-прежнему есть возможность вручную управлять временем жизни объекта с помощью динамической памяти. Много ли говноязыков дают тебе такие возможности? По сути все они предлагают только два пути: или довериться gc, или делать все ручками, как в C. Как по мне, так в плюсах альтернативы побогаче (и поэффективней).

>Не знаю, о чём там мечтает автор, а я об АТД мечтаю...

Тогда PHP тебе точно подойдет. Хотя нет, лучше Java или C# -- и рефлексия няшнее, и платить будут больше.

>По-моему, печалиться надо, что оно составляет кол-во процентов, сравнимое с 50.

Подумаешь -- много пропертей. Что с того? Кстати, если хочется "родных" пропертей, то тебе точно в C#. Тебе понравится: делегаты-хренегаты, gc, лямбды, linq и еще черте что. На свои убогие петуны потом возвращаться точно не захочется.

>Тогда PHP тебе точно подойдет. Хотя нет, лучше Java или C# -- и рефлексия няшнее, и платить будут больше.

afaik, нету в php алгебраических типов данных...

>Подумаешь -- много пропертей. Что с того?

Не пропертей много, а гетеров сетеров... честно говоря - это застрелиться, если их "даже чуть меньше 50%"

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

P.S. Претензии в стиле "вы ходите на ногах, потому что не осилили костыли, салабоны" -- это просто праздник какой-то.

> Для справки: циклические ссылки почти наверняка указывают на плохой дизайн.

Это - скорее мантра плюсофилов. Там действительно сложно обрабатывать циклические ссылки, вот они и придумали, что это - следствие плохого дизайна (sic!) программы на си/си ++. Заметь разницу. Не программы вообще, а именно программы на си/си ++. В языках с gc нет многих проблем, связанных с циклическими ссылками. Более того, часто такие ссылки - следствие особенностей задачи, и они зачастую являются вполне приемлемым и эффективным решением. То есть, не надо обобщать проблемы языков без gc на все другие. Глупо это.

Вы прослушали бессвязный поток мыслей на выдуманную тему в исполнении the_Shadow.

АО такие АО...

> Тогда PHP тебе точно подойдет. Хотя нет, лучше Java или C# -- и рефлексия няшнее, и платить будут больше.

В пыхе есть АТД? В жабе есть АТД? В до диезе есть АТД?

> Кстати, если хочется "родных" пропертей, то тебе точно в C#.

Я уже сказал, чего именно мне хочется. Прекрати спорить с выдуманным собеседником. Я понимаю, что плюсовщики способны видеть только на один шаг от своей любимой плюсовки, и поэтому у них слюни текут от пропертей. Но, так как "C++ рулит и педалит, и ваще в нём есть всё", они усиленно доказывают окружающим, что проперти не нужны, лучше в каждом классе воротить пол-класса сеттеров/геттеров. Это такая известная форма самообмана, да.

> На свои убогие петуны потом возвращаться точно не захочется.

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

> Waterlaz, мы тут "скриптовый быдлоязык С" с одним товарисчем обсуждали. Сделайте милость -- не вырывайте фразы из контекста.

"Скриптовый" С обсуждали как раз таки в контексте: чем он менее "скриптовый", чем Хаскелл и Окамл.

> "Скриптовый" С обсуждали как раз таки в контексте: чем он менее "скриптовый", чем Хаскелл и Окамл.

Во-первых, не совсем так. Читаем исчо разок одну из формулировок (остальные варианты сводились к ней же):

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

Цит. по Ответ на: Re: [C++?] Серьезный вопрос. от linuxfan 12.10.2009 16:38:40

Простите мне мою въедливость и даже занудство, но в формулировке я в упор не вижу словосочетания "скриптовый С". Предположим, оно там есть...

Хммм... А смысл такого обсуждения? Ну да... Есть интерпретаторы С.

По формальному признаку (коль скоро это "интерпретатор"), то оно ни чем не отличается. Слово "компилятор" там столь же важно, как и то же слово в отношении PHP. Что в одном случае это НЕ компилятор, что в другом. Хотя и честно "делает вид".

По признаку того, что есть "синтаксис" языка так тут и то проще -- С в виде интерпретатора будет в значительной мере уступать хаскелю в части "скорости" "программирования". Этого не отнять. В скорости исполнения такой программы он ("скриптовый С") будет так же уступать.

Однако, у того же интерпретатора С, если мы забьём благополучненько на навязываемые нам тут tcc, tcsh (уверяю kemm'а, я это видел так давно, что уже не помню когда на это забил). Так вот. Если мы забьём на явно фафно, которым нам тут пытаются впарить и возьмём более-менее толковую реализацию именно шелла с синтаксисом С (ссылочку ужо давал -> http://en.wikipedia.org/wiki/Ch_interpreter ). Так вот дальше всё становится куда как интереснее.

Единственная область применения такого интерпретатора (лучше всё-таки "шелла" как-никак оно больше похоже на "шелл" ("командную оболочку" или "командный процессор")) -- моделирование комплекса программ в виде синтаксически и семантически близком результирующему коду. По крайней мере мне лично это удаётся именно так использовать. У меня задачи куда как более скромные, нежели наукообразное онанирование над кодом. Во-первых, за это денег не платят, а во-вторых я женат. И... скрёб я до слёз то, что в Хаскеле "нестрогие структуры данных" и концептуально таки можно создать "бесконечную" структуру данных. Смысла в этом не вижу. Причины -- чуть выше.

В остальном обсуждать можно (наверное). Но после внимательного прочтения http://absurdopedia.wikia.com/wiki/Haskell Изумительно изложено... :D:D:D

>>Что там не так в плане производительности?

>Возьми icc, возьми окамлевский компилятор и сравни результаты.

Что за манера съезжать с неудобной темы? Речь шла о С++. Вот бери их программу на плюсах, gcc и icc и показывай, как там ускорить её на порядок. А то ты только трепаться можешь. Обещанного вычисления интеграла на С от тебя так и не увидели.

Ни хрена-то ты не понял...

Отлично.

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

> Простите мне мою въедливость и даже занудство, но в формулировке я в упор не вижу словосочетания "скриптовый С". Предположим, оно там есть...

Если ты так и не понял, Хаскелл и Окамл - статически типизованные компилируемые языки. И то, что для них есть интерпретаторы, этих свойств не отменяет.

> У меня задачи куда как более скромные, нежели наукообразное онанирование над кодом. Во-первых, за это денег не платят, а во-вторых я женат. И... скрёб я до слёз то, что в Хаскеле "нестрогие структуры данных" и концептуально таки можно создать "бесконечную" структуру данных. Смысла в этом не вижу.

Просто кодить на С++ (PHP, VB, 1C-скрипте и т.д.), если это приносит удовольствие и позволяет заработать - ничего плохого я в этом не вижу. Но считать всё то, что тебе непонятно - наукообразным онанированием - это уже идеология быдла.

> Но после внимательного прочтения http://absurdopedia.wikia.com/wiki/Haskell Изумительно изложено... :D:D:D

Изумительно, что ты это осилил. Кстати, там про С++ тоже есть.

> Возьми icc, возьми окамлевский компилятор и сравни результаты.

Окамль математику весьма бодро оптимизирует, btw.

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

>Кривые руки детектед.

Руки должны как минимум хорошо гнуться в локтях и в запястьях. Кроме того, у мужских рук весьма желателен мускульный рельеф.

>Для справки: циклические ссылки почти наверняка указывают на плохой дизайн.

man Observer design pattern

>>И вообще, смарт-указатели - говно.

>Говно - это сборщик мусора.

Мне эти плюсофильские мантры напоминают православное определение свободы - "свобода не во грехе, свобода от греха".

>>Ну да, С++ вынуждает передавать объект в объект по const-ссылке чтобы избежать копирования.

>Позволяет, а не вынуждает.

Опять "свобода от греха, не во грехе"

>>Вместо того чтобы просто описать поле объекта я должен еще обеспечить фан вида getXXX() const/setXXX().

>Это ты о пропертях мечтаешь? Хаха.

Я высмеиваю фан ради фана и "культы карго" в С++. В жабе все это get/set имеет вполне осмысленное наполнение - это технологии типа Beans, например.

>К сведению, геттеры и сеттеры составляют менее половины от общего числа методов в обычной программе на c++.

Мне вообще инфраструктурный код в программе нужен по минимуму. Если нужно описать структуру с тремя полями, то на это должно понадобиться максимум четыре строчки - одна строчка на имя и по строчке на каждое поле.

...Бред поскипан, оставляю только интересные для меня тезисы типа пулов...

>И, наконец, есть очень эффективные способы избежать фрагментации кучи и одновременно достичь скорости выделения O(const) для временных объектов. Так называемые "пулы". Но, похоже, ты о них не слышал или не использовал.

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

>>RAII это топорный сахар для сишного подхода "освобождаем ресурс на том же уровне где его аллоцировали".

>Во-первых, такого "сишного подхода" просто не существует в природе.

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

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

>Объясни мне принципиальную разницу между ручным вызовом malloc/free и open/close.

close() обычно происходит в конце того же самого блока. То же самое можно сказать о хендле открытой транзакции к БД. Для сложных случаев типа большого файла, куски которого мапируются по запросу, простая RAII-абстракция с деструктором типа InputStream совершенно не подходит.

Сервера/серверы на C++: http://www.sql.ru/forum/actualthread.aspx?tid=698411#7707919

> В жабе все это get/set имеет вполне осмысленное наполнение - это технологии типа Beans, например.

Бойлерплейт - он и в жабе бойлерплейт.

>В пыхе есть АТД? В жабе есть АТД? В до диезе есть АТД?

АТД = абстрактный тип данных? Это же массивы, множества, ассоциативные массивы, списки и т. д. Все это вроде как есть в джавах, пыхах, сишарпах.

Если уж ты используешь аббревиатуры, то будь добр либо использовать общепринятую форму их записи (ADT), либо расшифровывать свой бред.

>Но, так как "C++ рулит и педалит, и ваще в нём есть всё", они усиленно доказывают окружающим, что проперти не нужны, лучше в каждом классе воротить пол-класса сеттеров/геттеров.

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

> АТД = абстрактный тип данных? Это же массивы, множества, ассоциативные массивы, списки и т. д. Все это вроде как есть в джавах, пыхах, сишарпах.

Агы, АО начинают бредить по любому поводу, выдумывая аргументы за себя и "за того парня". АТД -- алгебраический тип данных.

> либо расшифровывать свой бред.

Переспрашивать надо, бредун, если не понял. 8))

> Твое пустословие начинает напрягать.

Моё? Это от тебя уже долго никак не можем дождаться:

1. объяснения, чем C -- менее скриптовый быдлоязыг, чем хаскелль с окамлом

2. интегральчиков

3. исправления быдлокода на C++, который наравне с окамлом был по скорости

4. наглядной демонстрации превосходства icc над gcc в 6 раз

Что-то ещё было, вроде. В зеркало посмотри.

> Как в твоем несуществующем идеальном языке выглядит декларация свойств?

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

>А то ты только трепаться можешь. Обещанного вычисления интеграла на С от тебя так и не увидели.

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

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

О Великий! Покажи же нам достойное применение этого наукообразного онанирования. Сколько лет ваш хацкиль существует, и все никому не нужен. Даже LISP нашел свое применение в виде emacs, а хацкиль как был никому не нужным, так никому не нужным и остался.

> Как в твоем несуществующем идеальном языке выглядит декларация свойств?

Так, между прочим. В хаскеле геттеры генерятся самим компилятором... В новом С# могут генерится тоже...

Нет, что говорить! В нашем время С++ выглядит динозавром. Но с другой стороны, у него есть сильные стороны. C++ - это прекрасный низкоуровневый ассемблер. Хотя это во многом наследие обычного С. Только как всегда, таким ассемблером нужно пользоваться очень осторожно. А то написать неэффективный или малоэффективный код на C++ проще простого [см. книгу, что я приводил выше].

>Окамль математику весьма бодро оптимизирует, btw.

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

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

Ты только подтверждаешь мою догадку о твоей умственной неполноценности. Использовать пулы для большого количества временных объектов -- это такое решение, которое должно приходить на ум сразу. Если оно не приходит, от имеем firefox, жрущий сотни мегабайт ОЗУ из-за фрагментации.

>Кто ресурс открыл, то его и закрывает.

Ты снова бредишь. Тебе никто не запрещает баловаться временем жизни объекта как тебе нужно. C++ просто несколько расширил концепцию лексической области видимости переменных и этот подход оказался просто фантастически удобным (man boost::scoped_lock). Если бы на ваших скриптовых поделках писалось что-нибудь серьезно-многопоточное, вы бы там утонули в дедлоках.

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

Правда? И чем же тебе не подходит концепция: "ресурс надо освободить, как только он стал никому не нужен"?

>АТД -- алгебраический тип данных.

А, это какое-то локальное понятие кружка онанирующих на монады?

>Переспрашивать надо, бредун, если не понял.

Бредун тот, кто не может переложить свои мысли на слова без потери смысла. В частности, от тебя нет ничего кроме воплей "в C++ нет фичи X!!1" Самое поразительное -- при этом ты, наверное, даже не понимаешь, для чего тебе может понадобиться эта фича. Я же тебе русским по белому предложил самый feature rich язык современности -- C#.

>1. объяснения, чем C -- менее скриптовый быдлоязыг, чем хаскелль с окамлом

Тем, что на нативном компилируемом C написаны десятки тысяч нужных и полезных приложений. На хаскелях и окамлях же балуются дети на различных контестах. Вот и вся разница.

>2. интегральчиков

Я написал прототипы. Разжевывать, куда надо добавить void *params я не намерен.

>3. исправления быдлокода на C++, который наравне с окамлом был по скорости

Сейчас, дарагой! Все брошу и побегу исправлять. Говорю же: just use icc.

>4. наглядной демонстрации превосходства icc над gcc в 6 раз

Не моя вина, что ты пешком под стол ходил, когда этот обзор висел толи на ixbt, толи еще на каком-то подобном крупном ресурсе.

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

Все понятно. Юношеская жажда познания мира. Это как подростковая гиперсексуальность -- с возрастом проходит.

>А то написать неэффективный или малоэффективный код на C++ проще простого [см. книгу, что я приводил выше].

Я прекрасно знаю, что C++ изобилует подводными камнями. Это плата за его высокоуровневость. Проблема в том, что ваши сриптовые поделки изобилуют такими тонкими местами ничуть не меньше, просто на них всем начхать, ибо поделки на то и поделки, что не используются практически никем.