Re[3]: Может я чего-то не понимаю....
От: vdimas Россия  
Дата: 06.08.23 19:17
Оценка:
Здравствуйте, Sm0ke, Вы писали:

S>Вы используете using-и, чтобы укоротить основную строчку, однако они сами добавляют отдельные строчки (хз честно это или нет).


Однократно на некий файл, допустим, с несколькими функциями манипуляций данными.


V>>Если "в одну строчку", то удобно использовать ренжи.

S>Там у вас две строки

В одну, в одну ))
Копирование в вектор было необязательным, поэтому вынес в отдельную строку, но можно было приписать последней операцией в строке.
Т.е. суть в том, что на каждом этапе стоит оперировать концепцией ренжей и только ими, сохранять в переменную можно тоже просто ренж — специально это продемонстрировал, показав ranges::copy(rng, out) без сохранения в промежуточный контейнер.

А уже конечный ренж копировать или в хранилище, или передать в output_iterator, или еще куда-нить для последующей обработки.


S>а если в одну, то for всё равно короче)


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

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


S>ranges::to — из 23-го стандарта


Есть такое.
Можно юзать ренжи из буста (первоначальный вариант был бустовый), бо в стандарт еще не все плюшки переехали.
В смысле ренжей, атомик и потоков (пусть даже в версии 4) и прочих emplace, optional и т.д. Boost, конечно, оказал чудовищное влияние на язык и его стандарты.
Красавцы, чо! ))


S>Однако для повторного использования забиндить цепочку изменений в переменную rng — конечно удобнее.


Концепт ренжей прямо в стандарте описан как тип, который имеет операции begin(rng) и end(rng), при том что дефолтная реализация пытается взять rgn.begin() и rng.end(), т.е. подхватывает имеющиеся стандартные контейнеры и пользовательские типы, оформленные в STL-like манере, экономя на стороне прикладного кода избыточный однообразный код, где ты оперировал парой итераторов явно, замусоривая исходник. Казалось бы — на поверности... Но когда-то сделано не было в STL из-за отсутствия полноценной поддержки частичной специализации шаблонов... Но тут, как грится, лучше поздно, чем никогда. ))
Отредактировано 06.08.2023 19:21 vdimas . Предыдущая версия . Еще …
Отредактировано 06.08.2023 19:19 vdimas . Предыдущая версия .
Отредактировано 06.08.2023 19:18 vdimas . Предыдущая версия .
Отредактировано 06.08.2023 19:17 vdimas . Предыдущая версия .
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.