Re[23]: Коллекции .NET и контейнеры STL
От: alex_public  
Дата: 06.04.12 11:23
Оценка:
>Здравствуйте, Qbit86, Вы писали:

Q>В предложенном решении не только контейнеры STL.


Это про Boost что ли? ) Ну он там только для красоты. ))) Например если заменить boost::lexical_cast на atoi то ничего принципиально не изменится. Просто не охота была с C-ми функциями мешать. И с остальным тоже самое.

Q>В отсутствии декларативности, наглядности, единообразия.


Это всё общие слова. Надо смотреть конкретный код. Вот сейчас и посмотрим...

Q>Вроде как было упомянуто, что Степанов стремился к «функциональности» своей библиотеки — где она в предложенном решении проявляется?


Вообще то это был пример не на функциональность, а на предложенное сравнение с .Net. Однако некоторые характерные для фунцкионального стиля элементы проскочили и здесь. А именно использование accumulate.

Q>Не вижу фильтрации по количеству чисел в строке: «Для всех строк, в которых более двух чисел...»


Аааа, я как-то упустил что там строгое неравенство в тексте. ОК, добавил строчку реализующую это в коде ниже.

Q>
Q>File.ReadAllLines("Numbers.txt")
Q>    .Select(line => line.Split(','))
Q>    .Where(numbers => numbers.Length > 2)
Q>    .Select(numbers => numbers.Aggregate(0, (total, number) => total ^ Int32.Parse(number)))
Q>    .OrderByDescending(result => result)
Q>    .ForEach(Console.WriteLine);
Q>


1. Эммм, а где программа то целиком? Где каркас, обработка ошибок, импорт? Как я это запускать буду для теста? Я по памяти не знаю что там должно быть в импорте, что бы оно заработало.

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

2. Хгм, так вот это и есть наглядность? Напоминает SQL в чистом виде. Для определённых целей конечно может быть очень удобно. Я даже знаю пару C++ библиотек для работы с базами данных, которые по такому же принципу работает. Но SQL в качестве универсальных контейеров языка, на все случаи жизни? Нее...

3. Eсли убрать весь лишний код, как в примере выше, то вариант на stl выглядит схожим по размеру (добавил тут строку, которую упустил в первом варианте) и простоте:

ifstream file("Numbers.txt");
multiset<int> result;
string row;
while(getline(file, row)){
    if(count(row.cbegin(), row.cend(), ',')<2) continue;
    tokenizer<char_separator<char>> numbers(row, char_separator<char>(","));
    result.insert(accumulate(numbers.begin(), numbers.end(), 0, [](int a, const string& n){return lexical_cast<int>(n);}));
}
for(auto i=result.crbegin(); i!=result.crend(); ++i) cout<<*i<<endl;


Но при этом он абсолютно другой по принципам работы — очень интересно какое же будет соотношение по быстродействию...

Q>В Clang 3.0 в предпоследней версии XCode (и в последней, судя по документации, тоже). И в поставляемом с XCode древним GCC. А под iOS 4.3 вообще печаль, C++11 использовать можно (хоть и без лямбд), а библиотеку из нового стандарта нельзя. Т.е. rvalue references вроде есть, но std::forward, std::move и прочей поддержки со стороны библиотеки — нет.


Хгм, на osx мы просто используем свой gcc, а не из xcode. Могу предположить что и на iOS можно что-то подобное сделать, правда утверждать не будут, т.к. не пробовал.
Re[24]: Коллекции .NET и контейнеры STL
От: Qbit86 Кипр
Дата: 06.04.12 12:05
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Можно предоставить код полноценный программы, а не этот огрызок? Я тут уже 100мб файлик случайных чисел заготовил для теста. ;)


К цивилизации я вернусь не раньше понедельника, так что придётся подождать.
Глаза у меня добрые, но рубашка — смирительная!
Re[23]: Коллекции .NET и контейнеры STL
От: Трололоша  
Дата: 06.04.12 19:25
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>но std::forward, std::move и прочей поддержки со стороны библиотеки — нет.

А самому их написать никак что ли?
... << RSDN@Home>>
Да, йа зелёный тролль!
Re[24]: Коллекции .NET и контейнеры STL
От: MxMsk Португалия  
Дата: 06.04.12 20:54
Оценка:
Здравствуйте, Трололоша, Вы писали:

Q>>но std::forward, std::move и прочей поддержки со стороны библиотеки — нет.

Т>А самому их написать никак что ли?
Господа, ну это нечестно. Алекса просили на stl, он туда boost впихнул. Тут спрашивают про состав библиотеки, так в ответ "самому написать". Вы как-то уж придерживайтесь предмета что-ли. Иначе можно и про производительность ДотНет-а утверждать "могу свой рантайм наваять, будет всех рвать"
Re[25]: Коллекции .NET и контейнеры STL
От: Трололоша  
Дата: 06.04.12 21:12
Оценка:
Здравствуйте, MxMsk, Вы писали:

Q>>>но std::forward, std::move и прочей поддержки со стороны библиотеки — нет.

Т>>А самому их написать никак что ли?
MM>Господа, ну это нечестно. Алекса просили на stl, он туда boost впихнул. Тут спрашивают про состав библиотеки, так в ответ "самому написать".

Ты в курсе что делают std::forward и std::move и как они устроены?
... << RSDN@Home>>
Да, йа зелёный тролль!
Re[25]: Коллекции .NET и контейнеры STL
От: alex_public  
Дата: 07.04.12 04:56
Оценка: 1 (1)
Здравствуйте, Qbit86, Вы писали:

Q>К цивилизации я вернусь не раньше понедельника, так что придётся подождать.


А я даже сумел справиться сам. Правда пришлось разок погуглить на тему вставки всяких там using System.Linq;

Так что я смог уже всё протестировать и результаты меня если честно, сильно удивили!

Начну по порядку. Значит тестировались куски кода выше (а потом и ещё кое-что). Оптимиация у обоих компиляторов включена. Тестировалось на файле состоящем из 1000 строк по 10 000 случайных int'ов.

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

Меня это результат сильно удивил. Я подумал что недооценил способность MS создавать оптимальный код и т.п... И так бы это удивление и осталось, если бы я не решил ради шутки проверить ещё один вариант. А именно, я написал код решающий задачу в лоб. Т.е. скорее в стиле C решение (хотя там всё равно был итоговый контейнер set<int>), без всяких красивостей (но и без какой-то спец. оптимизации). И вот этот код "неожиданно" показал быстродействие в 5 раз превышающее те два кода выше! Это было как раз похоже на то, что я ожидал, но только не от того кода...

И вот на этом месте моё удивление скорость работы .Net совсем прошло и заменилось удивлением по поводу некоторых элементов C++. ))) Есествено что я решил немного иследовать вопрос, посмотрев чуть подробнее на причины. И так весь код выше можно разделись на "загрузку из файла" (занимает приблизительно 1/4 времени) и "обработку данных".

Загрузка данных ускорилась в 10 (!) раз, в результате замены while(getline()) на одиночный fread. В принципе конечно так и должно быть... Но в свете данного факта запрет гугла на потоки, обсуждаемый в этой теме, не кажется таким уж и странным...

Код обработки данных становится быстрее приблизительно в 5 раз, если заменить 3 строчки красивого кода внутри цикла (в изначальном решение) на 7 строчек решения той же задачи в лоб, без всяких итераторов, лямбд, аккумуляторов. В принципе это тоже достаточно очевидно, т.к. решение в лоб позволяет произвести все манипуляции в один проход по данным, а не в несколько, как это происходит у красивого решения. Но всё же я несколько разочарован, что все эти красивости в стиле Boost'а "стоят так дорого", что откидывают производительность до уровня дотнетовской. Хотя... В большинстве случаев сейчас скорость разработки софта важнее скорости самого софта, так что подобные решения очень нужны и хорошо что у C++ оно есть по полной.
Re[25]: Коллекции .NET и контейнеры STL
От: alex_public  
Дата: 07.04.12 05:05
Оценка:
Здравствуйте, MxMsk, Вы писали:

MM>Господа, ну это нечестно. Алекса просили на stl, он туда boost впихнул. Тут спрашивают про состав библиотеки, так в ответ "самому написать". Вы как-то уж придерживайтесь предмета что-ли. Иначе можно и про производительность ДотНет-а утверждать "могу свой рантайм наваять, будет всех рвать"


Бррр, что там от Буста то было? Замена C-ных функций типа atoi их более красивым внешне аналогом? ) Даа, это конечно очень важно. )))

Это не говоря уже о том, что оно всё в h файлах, так что доступно где угодно по сути.
Re[26]: Коллекции .NET и контейнеры STL
От: Ночной Смотрящий Россия  
Дата: 07.04.12 22:11
Оценка:
Здравствуйте, alex_public, Вы писали:

_>А я даже сумел справиться сам. Правда пришлось разок погуглить на тему вставки всяких там using System.Linq;


Можно было просто поставить Решарпер, и ничего гуглить не понадобилось бы.

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


Так уперлось все в вывод в консоль

_>Меня это результат сильно удивил. Я подумал что недооценил способность MS создавать оптимальный код и т.п.


Ну у тебя и основания для выводов. No comments.

_>Загрузка данных ускорилась в 10 (!) раз, в результате замены while(getline()) на одиночный fread.


Что значит одиночный? Все сразу в память? В фреймворке есть более гуманный способ — BufferedStream.
Re[20]: std::first_rank_tensor
От: _d_m_  
Дата: 08.04.12 01:21
Оценка:
Здравствуйте, Ops, Вы писали:

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


Ops>>>А про вектор википедия говорит, что в программировании это одномерный массив.


___>>Ну такие же ландухи приплюснутые там и написали.


Ops>Я вот не пойму, как можно аргументировать что-то статьей из википедии, и сразу же писать, что в википедии туфта?


Я вот тоже не понял — и что ж я такого аргументировал статьей из педивикии?
... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
Re[11]: Вектор
От: Хвост  
Дата: 08.04.12 01:32
Оценка: +1
Здравствуйте, Qbit86, Вы писали:


Q>Не, точно гуманитарий. (А судя по смайликам, ещё и малолетний.) Мой комментарий выше про векторное пространство так и не понял. Вот, например, в WPF есть класс Vector, его экземпляры, по сути, элементы пространства, присоединённого к аффинному пространству Point'ов.


вектором испокон веков называется одномерный массив, википедия в помощь:
начинаем отсюда: http://en.wikipedia.org/wiki/Array_data_structure

Arrays are analogous to the mathematical concepts of vectors, matrices, and tensors. Indeed, arrays with one or two indices are often called vectors or matrices, respectively.


отсюда выражения "векторные инструкции", "векторный процессор" итд итп. Так что название vector для динамического одномерного массива считаю более чем адекватным.
People write code, programming languages don't.
Re[27]: Коллекции .NET и контейнеры STL
От: alex_public  
Дата: 08.04.12 09:20
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Можно было просто поставить Решарпер, и ничего гуглить не понадобилось бы.


Зачем мне его ставить ради маленького теста с форума? )

НС>Так уперлось все в вывод в консоль


Эмм, там вывод в консоль микроскопический же по сравнению со входными данными.

И вообще, логика то у вас хоть немного присутствует? ) Откуда тогда могло бы взяться ускорение кода в 5 раз при одинаковом выводе?

НС>Ну у тебя и основания для выводов. No comments.


Всегда хочется получить одновременно и красивый высокоуровневый код и не потерять в быстродействие. Как мы сейчас увидeли, .Net и STL (если использовать в лоб) обеспечивают красоту и краткость, но ценой огромного (в 5 раз по сравнению с тупым циклом, написаным за 1 минуту) падения быстродействия.

Кстати, получить высокоуровневый код не потеряв быстродействия с STL всё же можно, если подключить Boost. В смысле подключив для основных операций, а не в качестве украшательства (замены C функций), как в первом моём примере.

Вот такой код:
stringstream buf;
buf<<ifstream("Numbers.txt").rdbuf();

multiset<int> result;
vector<int> row;
auto calc=[&](...){if(row.size()>2) result.insert(accumulate(row.begin(), row.end(), 0, [](int a, int n){return a^n;})); row.clear();};
parse(buf.str().begin(), buf.str().end(), (*(int_[ph::push_back(ph::ref(row), _1)] % ',' >> -eol)[calc]));
for(auto i=result.crbegin(); i!=result.crend(); ++i) cout<<*i<<endl;

даёт увеличение быстродействия кода обработки в 5 раз (соответственно весь код становиться быстрее где-то в 3 раза) по сравнению с моим изначальным примером на STL и по сравнению с кодом .Net (хотя там я не знаю какая пропорция по времени у загрузки и обработки данных). Причём здесь остались наши тормознутые потоки C++. Если же их заменить на обычные C функции:

FILE* file=fopen("Numbers.txt", "rb");
fseek(file, 0, SEEK_END);
int size=ftell(file);
fseek(file, 0, SEEK_SET);
unique_ptr<char[]> buf(new char[size]);
fread(buf.get(), 1, size, file);
fclose(file);

multiset<int> result;
vector<int> row;
auto calc=[&](...){if(row.size()>2) result.insert(accumulate(row.begin(), row.end(), 0, [](int a, int n){return a^n;})); row.clear();};
parse(buf.get(), buf.get()+size, (*(int_[ph::push_back(ph::ref(row), _1)] % ',' >> -eol)[calc]));
for(auto i=result.crbegin(); i!=result.crend(); ++i) cout<<*i<<endl;

То загрузка файла ускоряется раз в 10 и соответственно получаем в итоге то самое преимущество в 5 раз. Причём код реализующий логику является у нас тут весьма кратким и выскоуровневым и может быть легко модифицирован (в отличие от моего быстрого кода написанного в виде цикла) для любых более сложных случаев. И при этом у нас преимущество в быстродействие в 500%.

Конечно быстродействие важно далеко не всегда и чаще важнее скорость разработки. Поэтому то .Net и существует. Но как мы видим, синтаксический сахар и быстродействие всё же можно совмещать...

НС>Что значит одиночный? Все сразу в память? В фреймворке есть более гуманный способ — BufferedStream.


Ну да, сразу. Это как раз быстро. Кстати, интересно а .Net ReadAllLines как внутри реализован. С чтением по запросу или же сразу грузит в память? )
Re[28]: Коллекции .NET и контейнеры STL
От: Ночной Смотрящий Россия  
Дата: 08.04.12 12:44
Оценка:
Здравствуйте, alex_public, Вы писали:

НС>>Можно было просто поставить Решарпер, и ничего гуглить не понадобилось бы.


_>Зачем мне его ставить ради маленького теста с форума? )


Ну посмотришь заодно, каким инструментарием люди пользуются

НС>>Так уперлось все в вывод в консоль


_>Эмм, там вывод в консоль микроскопический же по сравнению со входными данными.


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

НС>>Ну у тебя и основания для выводов. No comments.


_>Всегда хочется получить одновременно и красивый высокоуровневый код и не потерять в быстродействие.


Не, я про то что если МС, то априори некачественный код.

_> Как мы сейчас увидeли, .Net и STL (если использовать в лоб) обеспечивают красоту и краткость, но ценой огромного (в 5 раз по сравнению с тупым циклом, написаным за 1 минуту) падения быстродействия.


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

_>Конечно быстродействие важно далеко не всегда и чаще важнее скорость разработки. Поэтому то .Net и существует.


На дотнете тоже можно точно так же решить все в лоб. Той же, или даже чуть меньшей ценой.

_>Ну да, сразу. Это как раз быстро.


Ну так это изменение требований и сравнение уже некорректно.

_> Кстати, интересно а .Net ReadAllLines как внутри реализован.


using (StreamReader sr = new StreamReader(path, encoding))
  while ((line = sr.ReadLine()) != null)
    lines.Add(line);
Re[29]: Коллекции .NET и контейнеры STL
От: MxMsk Португалия  
Дата: 08.04.12 14:53
Оценка: 1 (1)
Здравствуйте, Ночной Смотрящий, Вы писали:

_>>Ну да, сразу. Это как раз быстро.

НС>Ну так это изменение требований и сравнение уже некорректно.
Так это типично для подобных "споров". Об этом когда-то шикарно написал
Автор: adontz
Дата: 19.03.09
adontz.
Re[29]: Коллекции .NET и контейнеры STL
От: alex_public  
Дата: 08.04.12 16:11
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Ну посмотришь заодно, каким инструментарием люди пользуются


Мне Нетбинса хватает для всего. )

Кстати, вот тут http://www.rsdn.ru/forum/tools/4678338.aspx
Автор: BabloZlo
Дата: 28.03.12
я заводил темку по подобным вопросам. )

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


В данном тесте данные специально так подобраны, что бы эти времена были несопоставимы между собой. Если бы использовали в файле данных строки по 2-3 числа, то реально влияло бы. А у нас по 10 000 чисел строки...

НС>Не, я про то что если МС, то априори некачественный код.


Я писал не про это, а про .Net. В том смысле что сделать на нём такое проблематично. Т.е. если бы у MS это вышло (как я на секунду подумал), то это было бы типа героическим свершением. Но как и ожидалось, чудес не бывает. )))

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


Бррр) Я закомментировал код вывода в консоль во всех вариантах и прогнал их тестом снова — изменение во времени выполнения порядка 2-3%. Можешь сам проверить. )

Так что давай вот как раз на этом конкретном примере и покажешь всё. ) Хотя я в целом и так догадываюсь — данный синтаксический сахар должен иметь последствий в виде создания промежуточных коллекций.

НС>На дотнете тоже можно точно так же решить все в лоб. Той же, или даже чуть меньшей ценой.


ОК, ну покажи на данном примере. Только пожалуйста пришли код сразу с разделом импорта, а то мне потом разбираться ещё...

НС>Ну так это изменение требований и сравнение уже некорректно.


Не понял, какое изменение требований? У нас стоит задача: есть исходный файл с числами и требуется вывести в консоль какие-то результаты. Какие ещё требования и где они изменялись?

_>> Кстати, интересно а .Net ReadAllLines как внутри реализован.

НС>
НС>using (StreamReader sr = new StreamReader(path, encoding))
НС>  while ((line = sr.ReadLine()) != null)
НС>    lines.Add(line);
НС>

Ага, т.е. загружает всё в память сразу, но построчно. Понятно. )
Re[30]: Коллекции .NET и контейнеры STL
От: Ночной Смотрящий Россия  
Дата: 09.04.12 17:13
Оценка: 1 (1)
Здравствуйте, alex_public, Вы писали:

_>Так что давай вот как раз на этом конкретном примере и покажешь всё. )


Выкладывай свой тестовый файл.

_> Хотя я в целом и так догадываюсь — данный синтаксический сахар должен иметь последствий в виде создания промежуточных коллекций.


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

НС>>Ну так это изменение требований и сравнение уже некорректно.


_>Не понял, какое изменение требований?


Файл может быть неприемлемо большим, чтобы его целиком в оперативку тащить.

_>Ага, т.е. загружает всё в память сразу, но построчно. Понятно. )


Я ж говорю, игрушечный метод. Достаточно переписать так:
using (StreamReader sr = new StreamReader(path, encoding))
  while ((line = sr.ReadLine()) != null)
    yield return line;


И все станет существенно интереснее.
Re[31]: Коллекции .NET и контейнеры STL
От: alex_public  
Дата: 09.04.12 18:46
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Выкладывай свой тестовый файл.


Нафига выкладывать 100мб файл случайных чисел? Я написал его генератор ровно в две строки, запустил разок и всё. Думаю не проблема ни для кого, на любом языке.

Значит у нас файл состоит из 1000 строк. Каждая строка это 10000 чисел разделённых запятой. Каждое число — это случайный 32 битный int (т.е. -2147483648 до 2147483647).

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


Ммм, а как тогда реализована команда split? И кстати ещё одна коллекция по любому должна создаваться — итоговая, т.к. по ней сортировка идёт. Но она есть и в C++ коде.

_>>Не понял, какое изменение требований?

НС>Файл может быть неприемлемо большим, чтобы его целиком в оперативку тащить.

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

НС>Я ж говорю, игрушечный метод. Достаточно переписать так:

НС>
НС>using (StreamReader sr = new StreamReader(path, encoding))
НС>  while ((line = sr.ReadLine()) != null)
НС>    yield return line;
НС>

Кстати это будет аналогом кода из моего примера на C++ с потоками. ) Там как раз читается по запросу по строке. И при этом хочу заметить что оно заметно медленнее варианта с загрузкой файла целиком. Хотя там ещё сами потоки тормознутые, поэтому из этого никаких выводов делать нельзя. )))

НС>И все станет существенно интереснее.


Ну посмотрим) Вообще говоря в C++ коде (который медленный вариант) загрузка занимала только 1/4 времени (и вообще эта пропорция существенно зависит от дисковой подсистемы компьютера). Не знаю как с этим в том .Net коде, но если предположить что так же, то сосредотачиваться надо на оптимизации совсем другого места.
Re[12]: Вектор
От: Qbit86 Кипр
Дата: 09.04.12 20:49
Оценка:
Здравствуйте, Хвост, Вы писали:

Х>вектором испокон веков называется одномерный массив, википедия в помощь:


Ну да, испокон веков вектор — структура данных «массив», а хитрозадые математики уже оттуда свистнули словечко.

Х>отсюда выражения "векторные инструкции", "векторный процессор" итд итп.


Векторные инструкции и векторный процессор — они немного о другом. Примерно как векторная запись сокращает нотацию по сравнению с покомпонентной для описания алгебраических операций. О том, чтобы рассматривать структуры данных динамических и несогласованных в компайл-тайме размеров и как контейнеры общего назначения для произвольных пользовательских типов, речи нет в контексте термина «векторный процессор».

Х>Так что название vector для динамического одномерного массива считаю более чем адекватным.


Это только если мозги травмированы сиплюсплюсом. Куда лучше, если они поражены математикой, имхо.
Глаза у меня добрые, но рубашка — смирительная!
Re[24]: Move semantics
От: Qbit86 Кипр
Дата: 09.04.12 21:00
Оценка:
Здравствуйте, Трололоша, Вы писали:

Q>>но std::forward, std::move и прочей поддержки со стороны библиотеки — нет.

Т>А самому их написать никак что ли?

Их-то я напишу, а остальную часть STL кто на их использование переведёт?
Глаза у меня добрые, но рубашка — смирительная!
Re[8]: Google code style
От: о_О
Дата: 09.04.12 21:14
Оценка:
N>хорошо, вам, плюсовикам. всегда есть о чем поболтать

вступай и компелируй1
Re[24]: Fluent syntax, query syntax
От: Qbit86 Кипр
Дата: 09.04.12 22:19
Оценка: -1 :)
Здравствуйте, alex_public, Вы писали:

Q>>Вроде как было упомянуто, что Степанов стремился к «функциональности» своей библиотеки — где она в предложенном решении проявляется?

_>Вообще то это был пример не на функциональность, а на предложенное сравнение с .Net.

Да нет, как раз хотелось
Автор: Qbit86
Дата: 05.04.12
увидеть идиоматичные примеры использования стандартных ФВП: свёртки (редукции, аггрегации, катаморфизма), проекции, фильтрации. Всю эту неуклюжесть при работе с итераторами и падение эффективности из-за энергичного создания промежуточных коллекций при работе с алгоритмами STL (малоюзабельность которых нашла своё подтверждение в твоём примере).

_>Я по памяти не знаю что там должно быть в импорте, что бы оно заработало.


Тут бы ты на моём месте обязательно придрался к знанию стандартной библиотеки.

_>2. Хгм, так вот это и есть наглядность?


Да, она, родимая.

_>Напоминает SQL в чистом виде.


Это был fluent syntax. Оно бы действительно напоминало SQL, если бы я использовал query syntax:
var results = from line in File.ReadAllLines("Numbers.txt")
              select line.Split(',') into numbers
              where numbers.Length > 2
              select numbers.Aggregate(0, (total, number) => total ^ Int32.Parse(number)) into result
              orderby result descending select result;
foreach (var result in results)
    Console.WriteLine(result);


_>Но SQL в качестве универсальных контейеров языка, на все случаи жизни? Нее...


Ты выше упоминал про списки в Lisp и Haskell. Очевидно, это был пустой звон, и ты не представляешь, как происходит в них работа со списками; иначе ты бы никогда не сказал процитированного. Я бы на твоём месте не разбрасывался остроумными уколами типа «Чем знание другого языка может помочь не разбирающимся в тонкостях C++, но желающим поговорить о них?»

_>3. Eсли убрать весь лишний код, как в примере выше, то вариант на stl выглядит схожим по размеру (добавил тут строку, которую упустил в первом варианте) и простоте:

_>ifstream file("Numbers.txt");
_>multiset<int> result;
_>string row;
_>while(getline(file, row)){
_>    if(count(row.cbegin(), row.cend(), ',')<2) continue;
_>    tokenizer<char_separator<char>> numbers(row, char_separator<char>(","));
_>    result.insert(accumulate(numbers.begin(), numbers.end(), 0, [](int a, const string& n){return lexical_cast<int>(n);}));
_>}
_>for(auto i=result.crbegin(); i!=result.crend(); ++i) cout<<*i<<endl;


Дело не только в количестве строк или лексем, дело в скорости и простоте восприятия. Декларативность vs. кондовая императивность.
Глаза у меня добрые, но рубашка — смирительная!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.