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

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

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


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

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

А уже конечный ренж копировать или в хранилище, или передать в 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 из-за отсутствия полноценной поддержки частичной специализации шаблонов... Но тут, как грится, лушче поздно, чем никогда. ))

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

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

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


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

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

А уже конечный ренж копировать или в хранилище, или передать в 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 из-за отсутствия полноценной поддержки частичной специализации шаблонов... Но тут, как грится, лушче поздно, чем никогда. ))