Комментарии 36
Не могли бы вы уточнить, что вам не нравится в коде, который упомянут в заключении? Да, ваш вариант короче, но при чём здесь эффективность? Алгоритмическая сложность одинаковая, особого оверхеда я тоже не вижу. В чём проблема?
Так уж и редкий гость. Самая горячая тема! Вот пара постов: исходник, и ответ на него.
На C++ не пишу, но с замиранием сердца читаю новости про расширение стандарта. Кто всё это сможет объять?
Не думаю что причитания про необъятность стандарта уместны как минимум в этом вопросе.
На C++ не пишу, но с замиранием сердца читаю новости про расширение стандарта. Кто всё это сможет объять?
ИИ написанный на java? ;)
Завершение статьи, конечно, фееричное:
Я ненавижу range-based цикл for, потому что он мотивирует людей писать его везде где нужно и где не нужно, из-за чего зачастую ухудшается лаконичность кода
Стандарт словно движется в сторону Java Streams или LINQ. А ценой лаконичности будет понижение производительности, когда неофиты набегут и будут совать это везде
К нему кроме многословности ещё вопросы возникают.
ranged-for оперирует началом, концом и оператором ++.
Хочешь — запускай для вектора; хочешь — для списка или вообще собственного контейнера.
Но если контейнер, например, банальный вектор. И операция — удвоить всего его элементы — то за абстракцией ranged-for скрывается возможность поделить его на 8 частей и запустить операцию параллельно на 8 ядрах процессора. Потому что "8 частей" никак не вытащить из примитивов начало, конец и инкремент.
Тем не менее, я ими (циклами) пользуюсь. Всё таки сахар они, зараза, сладкий ) Даже синтаксический. Но, конечно, только там, где это не бьет по эффективности.
Только в отличие от Java и C# всегда можно будет фоллбэкнуться до эффективной реализации, не меняя контекст языка. Когда этот цикл станет бутылочным горлышком — ну ты пойдешь и заоптимизируешь, а пока так.
объединив итераторы на начало и конец вектора в один объект
А сам объект вектора не является тем самым объединением? Ей-богу, более уродливого синтаксиса и api чем в С++ найти невозможно…
Нет, не является. Тогда было бы возможно иметь только один интервал.
на самом деле, эта концепция уже очень хорошо развита в Питоне, особенно прикольно то, что генераторные интервалы делают вычисления генерируемых последовательностей «ленивыми».
но как таковая эта концепция не является чем-то новым в мире метапрограммирования, просто тема актуализировалась тем, что её хотят стандартизировать.
Большинство техник на большинстве архитектур исторически базируется на применении адреса и счётчика, включая hardware. Например DMA или инструкции REP MOV (x86) или LDIR (z80). Я помню только одну подобную технику — её использовали процедуры «монитора» Радио-86РК и «Специалист». Они тоже копировали данные с указанием адреса первого и последнего байтов блока. Не адреса за блоком, как это делает STL, а именно последнего. Это может быть иногда удобно при ручной работе с командами копирования блоков памяти, но неудобно (и медленно) при непосредственном программировании.
Сама семантика структур данных естественного мира в подавляющем большинстве случаев основывается на предположении количества элементов, а не на указании последнего.
При этом большинство библиотек/реализаций/high-level языков программирования предоставляет массивы/контейнеры хранящие свою длину. Для них не требуется указывать начало-конец контейнера, указывается только его имя (а также если необходимо — смещение и длина).
Так что это не «будущее», а очередная заплатка на неудобный/ошибочный/freaky дизайн. Многие заплатки Modern C++ — синтаксический сахарок, не привносящий actual value.
пришла в делириуме после отравления рыбой
это многое объясняет!
Не могу согласиться "в подавляющем большинстве". Если уж про то говорить, то в интернете в подавляющем большинстве находятся сайты, написанные поверх базы данных (готовой или самописной), а размер ответа запроса от той базы данных может не знать никто. Можно селектнуть из nosql базы итератор на ответ совершенно неясного размера, там может быть десять терабайт данных в хвосте запроса. Более того, сейчас уже нормально, что ответ этот может меняться, в той части, которую клиент ещё не видит, и с ним могут происходить разные другие трансформации. Для этого нужен крайне ленивый асинхронный API, такие операции поддерживающий.
Мне кажется, тут есть некая большая проблема в видении языка. Разработчики стандарта думают о C++ как об универсальном языке для всего на свете — не менее универсальном, чем джава, сишарп или питон, но с другим набором стартовых предположений и трейдоффов. Но есть парочка узкоспециализированных категорий разрабов, например эмбеддед и геймдев, которые считают что C++ — их личный язык и никого другого они рядом не потерпят. И вот тут начинается великая битва :)
Мне кажется, тут есть некая большая проблема в видении языка. Разработчики стандарта думают о C++ как об универсальном языке для всего на свете — не менее универсальном, чем джава, сишарп или питон
«строго более» универсальном. Всё-таки с++ применим еще и там, где интерпретаторы/вм либо не работают, либо работают недостаточно быстро.
Но если использовать трансформирующий адаптер (transform adaptor), то всё выглядит гораздо более лаконично:
Да как-то не увидел я там лаконизма: примерно одинакового размера фрагменты. Меня как-то вот эти фильтры и адаптеры не радуют. Да, я прекрасно помню, как использовать bind(), men_fn() и тому подобное, но в эпоху до C++11 выбор обычно был между «собери предикат из готовых кусков» и «пиши отдельную функцию/функциональный объект». Когда появились лямбды, стало возможно прямо на месте чётко выразить, чего хочется. А теперь вы предлагаете опять собирать простой и ясно выглядящий критерий вида «a.id == 4» из каких-то кусков, которые читающему ещё расшифровывать надо. Попробуйте заменить мысленно выражение под оператором if() таким вот кодом. Никто же так не пишет, и неудивительно.
Из моего опыта, код на нынешних алгоритмах в среднем значительно короче. Просто это плохо заметно на совсем тривиальных примерах, как в статье.
Интервалы: грядущая эволюция C++