C++ дайджест #25: засідання комітету зі стандартизації С++ 20, online-компiлятори та задачі для практики

Привіт, мої любі сішники! В цьому випуску пропоную ознайомитися зі звітами засідання комітету з питань стандартизації С++20 в Празі. А також до вашої уваги список ресурсів для тренування у розв’язанні задач, список online-компіляторів та найсвіжіші оновлення і статті лютого. Почнімо? :)

Засідання комітету стандартизації: звіти

Звіт від Саттера

Відео: C++20 is here!

Повний звіт на Reddit

Trip report: ISO C++ standards in Prague — Inbal Levi

Задачі для практики

В коментарях до попереднього дайджесту піднімалося питання про ресурси, на яких можна попрактикуватися в розв’язанні задач. Вирішила зібрати ресурси з задачками — доповнюйте у коментарях! :)

Для самого початку:

Вирішувати можна в online-компіляторах:

Modern C++

How to Make for_each Stop When a Condition Is True

Reverse For Loops in C++

Various Ways of Applying a Function to the Elements of a Collection in C++

How to Make for_each Stop After N Elements

A quick primer on type traits in modern C++

Literal Classes as Non-type Template Parameters in C++20

C++20: Functional Patterns with the Ranges Library

Concepts in C++20: An Evolution or a Revolution?

A few experimental features C++23

C++ 17 New Attributes

Корисні посилання

GitHub trends

Tips for Optimizing C/C++ Code

Virtual, final and override in C++

Move, simply

References, simply

C++ Regex 101

The Performance Benefits of Final Classes

C++17 Signal-Slots

Invariants and Preconditions

Super compact serialisation of C++ classes

Should there be a standard C++ pattern for this? transform_to

Інструменти

Visual Studio 2019: Analyze your builds programmatically with the C++ Build Insights SDK

Visual Studio 2019 16.5, Preview 2: Code Navigation for CMake Scripts

Visual Studio 2019 16.5, Preview 2: Easily Add, Remove, and Rename Files and Targets in CMake Projects

Visual Studio Code CMake Tools Extension: Multi-root workspaces and file-based API

Qt to support Visual Studio Linux projects/Cross Platform Development with Qt and Visual Studio

Export your Qt Project from VisualStudio to CMake (...or how I stopped worrying and learned to love CMake!)

PVS-Studio Integration in PlatformIO

QML Type Registration in Qt 5.15

Оновлення

Цього місяця маємо такі оновлення:

Хвилиночка флуду




← Попередній випуск: C++ дайджест #24
Наступний випуск: C++ дайджест #26

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному2
LinkedIn



21 коментар

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Статті

How to Make for_each Stop When a Condition Is True

та

How to Make for_each Stop After N Elements

мали б складатися з одного речення: «Якщо виникла необхідність таке робити — не використовуйте for_each».

How to Make for_each Stop When a Condition Is True

в последнее время этот сайт становится очаровательнейшим местом куда уже вопросы у всех «а нахиба вообще так писать затем героически с этим сражаясь?»

собственно на сегодняшний день это один из головных вопросов к «плюсам» вообще может даже не к самим «плюсам» но к их «прикладному применению»

Так альтернативы все частичные и по-своему кривоватые.
Прямо хоть своё начинай рисовать... :( (15_конкурирующих_стандартов.jpeg)

может даже не к самим «плюсам» но к их «прикладному применению»

А если ещё точнее, то к их прикладному применению теми людьми, которым пока что не хватает опыта писать код просто. Особенно джуны этим грешат: «я выучил крутую фишку, применю-ка я её вот здесь!» — не понимая, что настоящий мастер кунг-фу не применяет кунг-фу без необходимости :)
Сам таким был лет пять назад.
Сейчас я бы в такой ситуации вместо вот этой вот велосипедной модификации std алгоритма предпочёл обычный ручной цикл.

Особенно джуны этим грешат:
Сам таким был лет пять назад.

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

Что касается образования в Бразилии, то у меня был очень интересный
опыт. Я вел группу студентов, которые впоследствии должны были стать
преподавателями, так как возможностей для научной работы в Бразилии в то
время почти не было. Мои студенты прошли уже много предметов, а это должен
был быть их самый серьезный курс по электричеству и магнетизму — уравнения
Максвелла и т.д.
Университет располагался в нескольких зданиях, разбросанных по городу,
и я вел свои занятия в здании, окна которого выходили на залив.
Я обнаружил очень странное явление: я задавал вопрос, и студенты
отвечали, не задумываясь. Но когда я задавал вопрос еще раз — на ту же тему
и, как мне казалось, тот же самый вопрос, они вообще не могли ответить!
Например, однажды я рассказывал о поляризации света и раздал им всем кусочки
поляроида.
Поляроид пропускает свет только с определенным направлением
поляризации. Поэтому я объяснил, как определить направление поляризации
света по тому, темный поляроид или светлый.
Сначала мы взяли две полоски поляроида и вращали их до тех пор, пока
они не пропустили максимум света. Теперь мы могли сказать, что две полоски
пропускают свет, поляризованный в одном направлении: что пропускает один
поляроид, может пройти и через второй. Но потом я спросил, можно ли, имея
всего один кусок поляроида, определить, в каком направлении он поляризует
свет. Они совершенно не представляли себе.
Я знал, что это требует известной доли находчивости, поэтому я
подсказал: «Посмотрите на залив. Как от него отражается свет?»
Все молчат. Тогда я сказал:
— Вы когда-нибудь слышали об угле Брюстера?
— Да, сэр. Угол Брюстера — это угол, отражаясь под которым от
преломляющей среды, свет полностью поляризуется.
— В каком направлении свет поляризуется при отражении?
— Свет поляризуется перпендикулярно плоскости падения, сэр.
Даже теперь я не могу этого понять. Они знали все наизусть. Они знали
даже, что тангенс угла Брюстера равен показателю преломления!
Я сказал: «Ну?»
По-прежнему, ничего. Они только что сказали мне, что свет, отражаясь от
преломляющей среды, как, например, воды в заливе, поляризуется. Они даже
сказали, в каком направлении он поляризуется.
Я сказал: «Посмотрите на залив через поляроид. Теперь поворачивайте
поляроид».
— О-о-о, он поляризован! — воскликнули они.
После длительного расследования я, наконец, понял, что студенты все
запоминали, но ничего не понимали. Когда они слышали «свет, отраженный от
преломляющей среды», они не понимали, что под средой имеется в виду,
например, вода. Они не понимали, что «направление распространения света» -
это направление, в котором видишь что-то, когда смотришь на него, и т.д. Все
только запоминалось, и ничего не переводилось в осмысленные понятия. Так
что, если я спрашивал: «Что такое угол Брюстера?», я обращался к компьютеру
с правильными ключевыми словами. Но если я говорил: «Посмотрите на воду», -
ничего не срабатывало. У них ничего не было закодировано под этими словами.
Позже я посетил лекцию в Инженерном институте. Проходила она так:
«Два тела... считаются эквивалентными... если равные вращательные
моменты... производят... равное ускорение. Два тела считаются
эквивалентными, если равные вращательные моменты производят равное
ускорение». Студенты сидели и записывали под диктовку, а когда профессор
повторял предложение, они проверяли, все ли правильно записано. Потом они
писали следующее предложение и еще одно, и еще одно. Только я один знал, что
профессор говорил о телах с одинаковыми моментами инерции, а уяснить это
было трудно.
Я не понимал, как они смогут разобраться во всем этом. Вот речь шла о
моменте инерции, но не было никакого обсуждения хотя бы такого примера: ты
хочешь открыть дверь и толкаешь ее с одной стороны, а с другой стороны ее
подпирают грузом то с краю, то у самых петель. Насколько труднее будет
открыть ее в первом случае, чем во втором?
После лекции я спросил одного студента:
— Вы ведете все эти записи. Что вы с ними делаете?
— О, мы их заучиваем. У нас будет экзамен.
— А какой будет экзамен?
— Очень простой. Я могу Вам прямо сейчас назвать один из вопросов, — он
заглянул в тетрадь и сказал: «В каком случае два тела считаются
эквивалентными?». А ответ: «Два тела считаются эквивалентными, если равные
вращательные моменты производят равные ускорения».
Так что, как видите, они могли сдавать экзамены, и «учить» все это, и
не знать абсолютно ничего, кроме того, что они вызубрили.
Потом я был в Инженерном институте на вступительном экзамене. Экзамен
был устный, и мне разрешили послушать. Один абитуриент был просто
великолепен. Он отлично отвечал на все вопросы. Его спросили, что такое
диамагнетизм. Он ответил совершенно правильно. Потом его спросили: «Что
происходит с лучом света, когда он проходит под определенным углом через
слой материала определенной толщины и с определенным показателем
преломления?»
— Он выходит, сместившись параллельно самому себе, сэр.
— А на сколько он сместится?
— Я не знаю, сэр, но я могу посчитать.
Он посчитал. Все было прекрасно. Но у меня к этому времени уже были
подозрения.
После экзамена я подошел к блестящему молодому человеку и объяснил, что
я из Соединенных Штатов и хочу задать несколько вопросов, которые никак не
повлияют на результат экзамена. Для начала я спросил, может ли он привести
какой-нибудь пример диамагнетика.
— Нет.
Тогда я сказал: «Представьте себе, что эта книга стеклянная, и я смотрю
сквозь нее на что-нибудь на столе. Что случится с изображением, если
наклонить стекло?»
— Изображение повернется, сэр, на угол, в 2 раза превышающий угол
наклона.
— А вы не путаете с зеркалом?
— Нет, сэр.
Он только что сказал на экзамене, что луч света сместится параллельно
самому себе, и, следовательно, изображение сдвинется в сторону, но не будет
поворачиваться ни на какой угол. Он даже вычислил, насколько изображение
сдвинется, но он не понимал, что кусок стекла — это и есть материал с
показателем преломления и что его вычисления имели самое непосредственное
отношение к моему вопросу.

/ Вы, конечно, шутите, мистер Фейнман! /

ЗЫ: запятые в тексте авторские ))

Отличные букавы. И далеко не только к Бразилии это применимо :)

т.е. понимаешь ли какая фишка я давно заметил что если брать на примере for_each то они просто заучили что есть for_each и чтобы сделать итерацию по контейнеру либо там range надо сделать for_each и внутри лямбду и всё

они не знают что такое for_each
они не знают что такое лямбда

за лямбду вообще почти никто в принципе ))

задаю наводящие вопросы мол лямбда появилась в 11-м правильно? ну да правильно (тут надо понимать в этом месте они прямо не понимают к чему веду) но for_each был до 11-го так как же ж работал? ноль на массу

как результат приходится «разбираться» в коде вот реально пусть условно иллюстративно «тут мы сделали for_each а тут мы придумали как из него выходить досрочно»

youtu.be/WbCMdaTC0pQ

но «разбираться» это скорее уже следствие ну и потом за это и плотят )) обидно же ж именно за то про что написал ещё сам мр. Фейнман

ЗЫ: не ну и да по-своему обидно что плотят за то чтобы «разбираться» а хочется же ж как мр. Фейнман ядрёну бомбу ))

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

Лямбды это вообще отдельная тема. Они — такая себе «квинтэссенция» плюсов. В плане того, что по-настоящему ты их понимаешь только если понимаешь кучу других разделов языка. У Джейсона Тёрнера был выпуск об этом: www.youtube.com/watch?v=CjExHyCVRYg

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

сирёзно? йопта простите это же ж просто синтаксический сахарок к функторам ))

тут фишка именно не в том что

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

а что именно у человека есть знание что вот есть лямбда даже со всякими нюансами там кого и как захватывать но понимания что такое оно под капотом нет вообще именно настолько что человек просто не задумывается что там что-то может быть под капотом причём здесь именно «не задумывается» именно как принцип

ну хорошо вопрос на «с плюсиком» нарисуй лямбду на чистых сях вот просто отбросив синтаксический сахарок но как принцип ну или скажем в другую сторону во что собственно это лябда скомпилируется если смотреть на код на чистых сях?

ЗЫ: да что там лямбда для многих this является откровением хотя справедливости ради это совсем уж «ниже среднего уровень» тут соглашусь но таких тоже бывает ))

такая себе «квинтэссенция» плюсов

ЗЫ: т.е. вот смотри убираем лямбды и всё человек встал больше писать он не может потому что умеет только так причём именно дословно

У Джейсона Тёрнера был выпуск об этом: www.youtube.com/watch?v=CjExHyCVRYg

понимаешь какая тут штука тут полностью по тов. Фейнману приходят люди которые знают именно знают много страшных слов ну там return type deduction вот это всё они даже могут показать где это в лямбде но что это и как оно это всё «шаг вправо шаг влево побег» (к) (тм) они именно не «плавают» просто потому что это уже не «заученное знание на экзамене» они именно не задумывались про это просто потому что они «заучены» именно _не_ задумываться

и более того им именно _не_ интересно ))

не то чтобы конкретно это но именно вообще

ЗЫ: другой мой любимый вопрос вот сейчас 20-й стандарт выходит а что там лично вам такого интересного вот такого что было нннада но не было либо такого что посмотрели увидели и такой оп-па так это же ж круто и так очевидно и вообще!

ЗЫ: хочешь я тебе другой хинт покажу? )) вот на видео товарищ выступает показывая консоль ассемблера во что на самом деле превращается лямбда то что такое сугубо абстрактное знание доступно ну может 5% реальных программистов — что код си++ вообще можно сопоставить с бинарным кодом процессора — это вопрос десятый хотя тоже где-то про это но вот даже посмотрев это видео и в общем признав такую возможность ты думаешь люди смогут ею воспользоваться на практике?

простой вопрос вот у нас тут лямбда вот это всё но как там насчёт производительности? только реально гуру ну либо просто _реально_ синьор сможет сопоставить одно с одним и сказать «понты делов у нас же ж есть ассемблерный код давайте тупо возьмём и посмотрим и сразу всё и увидим»

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

ЗЫ: ну а ок а как насчёт замены индукции «магическим мышлением»? ))

такая себе «квинтэссенция» плюсов
сирёзно? йопта простите это же ж просто синтаксический сахарок к функторам ))

Вот именно. А чтобы понимать функторы, нужно понимать принципы построения стандартной библиотеки, перегрузку операторов, шаблоны и выведение типов в них, const/mutable и ещё ряд тем.
Да и этот «просто синтаксический сахарок» делает под капотом вещи, неочевидные для типичного новичка, про которого ты рассказываешь. Но о которых, при этом, всё же знать стоит, чтобы не напороться на грабли.

Хорошо, когда человек понимает, что лямбда-выражение генерирует анонимный тип с перегруженным оператором() и создаёт его инстанс на месте. И как при этом происходит захват переменных из окружающего скоупа (и что вообще такое этот «захват» в терминах старого C++98/03).
Без понимания таких штук можно написать фигни, которая в лучшем случае не скомпилится, в худшем приведёт к некорректной работе программы в рантайме.

ну хорошо вопрос на «с плюсиком» нарисуй лямбду на чистых сях вот просто отбросив синтаксический сахарок но как принцип ну или скажем в другую сторону во что собственно это лябда скомпилируется если смотреть на код на чистых сях?

Это хороший вопрос, только я не понимаю, зачем именно на чистых сях. Если собеседуешь плюсовика, то, по-моему, лучше попросить его реализовать лямбду на C++98/03. Дать конкретный пример кода с лямбдой, и пусть перепишет без лямбд (с явным функтором). Чтоб правильно «перевёл» все захваты и т.д.
Если копать ещё глубже, то можно потом дать так же переписать mutable лямбду и/или лямбду которая принимает auto&.
Справится — значит понимание есть.

а что именно у человека есть знание что вот есть лямбда даже со всякими нюансами там кого и как захватывать но понимания что такое оно под капотом нет вообще именно настолько что человек просто не задумывается что там что-то может быть под капотом причём здесь именно «не задумывается» именно как принцип

Мы с тобой просто вкладываем чуть разный смысл в одни и те же термины.
Лично для меня это «есть знание, но нет понимания что там под капотом» звучит как оксюморон. Я считаю, если человек не понимает, как под капотом устроены лямбды, то знания этой темы (кроме, разве что, очень поверхностного) у него нет.

понимаешь какая тут штука тут полностью по тов. Фейнману приходят люди которые знают именно знают много страшных слов ну там return type deduction вот это всё они даже могут показать где это в лямбде но что это и как оно это всё «шаг вправо шаг влево побег» (к) (тм) они именно не «плавают» просто потому что это уже не «заученное знание на экзамене» они именно не задумывались про это просто потому что они «заучены» именно _не_ задумываться

Опять же, недопоняли друг друга из-за отличий в терминологии.
Я примерно об этом и говорил, когда сказал «плавают». В моём понимании, если человек на первый вопрос отвечает и вроде бы показывает намёк на знания, а затем ты его спрашиваешь «шаг вправо шаг влево» и он уже сыпется, значит в теме в целом он «плавает».

вот на видео товарищ выступает показывая консоль ассемблера во что на самом деле превращается лямбда то что такое сугубо абстрактное знание доступно ну может 5% реальных программистов — что код си++ вообще можно сопоставить с бинарным кодом процессора

То видео было не об асме. В данном случае godbolt он просто открыл как редактор кода. В других выпусках он и правда показывает асм, да. Но здесь он просто рассказывал, в какой C++ код разворачивается лямбда-выражение и какие темы из core language это затрагивает.

простой вопрос вот у нас тут лямбда вот это всё но как там насчёт производительности? только реально гуру ну либо просто _реально_ синьор сможет сопоставить одно с одним и сказать «понты делов у нас же ж есть ассемблерный код давайте тупо возьмём и посмотрим и сразу всё и увидим»

Эх, мы с тобой опять упираемся в слишком большую разницу нашего личного опыта.
Я видел, как такое «давайте посмотрим на асм и сразу всё увидим» делали синьоры, когда я сам ещё был джуном. Чуть прокачавшись, где-то на уровне начинающего миддла я и сам такое спокойно делал.
Прикольно, конечно, если для кого-то я с такими навыками буду считаться «гуру/синьором» :) Я сам себя пока считаю стронг миддлом.

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

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

ЗЫ: и кстати в этом месте общее «недовольство» плюсами мол «всё так сложно куча возможностей в т.ч. себе в ногу» т.е. современная индустрия уже прямо предложила технологию и возвела уже в ранг идеологии именно как принцип «чтобы сделать то-то возьми for_each чтобы сделать выход с for_each возьми for_each с выходом ( как вариант в новой версии новая фишка языка-платформы которая прямо делает выход с for_each )»

ЗЫ: отсюда же ж как следствие продолжение все эти фишки с литкоддрочевом )) это же ж ровно та же ж история селяви

Ну вот не знаю. Предложила технологию — да; возвела в ранг идеологии — здесь уже не совсем согласен.
В моей команде, например, упоротых «идеологов» чего-либо нет. Где удобно использовать std’шный алгоритм — используем алгоритм; где будет проще и читабельнее заюзать обычный олдскульный цикл — не выделываемся и пишем цикл.
Знать в любом случае нужно о нескольких возможностях, а не лепить одну «серебрянную пулю» везде. Если человек знает только про алгоритмы и не знает про ручные циклы... кхм... это даже не джун ¯\_(ツ)_/¯

В ранг идеологии возводят отдельные люди.
Например, Шон Перент из Adobe предлагал принципы чистого кода, одним из которых было «no raw loops» (www.youtube.com/watch?v=W2tWOdzgXHA). В частности он топил за то, чтобы заменять по возможности сырые циклы алгоритмами.
Правда, в его примерах это и правда выглядело достаточно элегантно и в целом оправданно. Но если какой-то джун это послушает, «проникнется» и воспримет буквально за какую-то абсолютную истину, которой нужно придерживаться вообще всегда без исключений... будет не очень хорошо.

В моей команде, например, упоротых «идеологов» чего-либо нет.

ты не совсем правильно просто не понял об чём я

я говорю об идеологии когда есть правило «чтобы сделать перечисление по массиву возьмите for_each» отдельно и есть правило «чтобы сделать выход из for_each возьмите exit_for_each»

здесь «идеология» в том что не нужно знать что там внутри достаточно просто делать по правилам и оно будет работать

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

Если человек знает только про алгоритмы и не знает про ручные циклы... кхм... это даже не джун ¯\_(ツ)_/¯

гыгы об этом же ж и речь )) но нюанс тут ещё и в том что человек может знать и про алгоритмы и про циклы но никак их не сопоставлять от слова вообще просто потому что идеология этого именно _не_ подразумевает

т.е. скажем умеет человек писать цикл for (int i = 0; i < 100; i++) { sum += m[i]; } и всё он так берёт и пишет просто потому что это работает более того сопоставить это с тем же ж for (i : sum) он уже не сможет просто потому что это уже просто _другое_ «правило» которое тоже просто работает ))

ручные циклы отдельно алгоритмы отдельно ))

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

я практически не слушаю и не смотрю всех этих выступлений реального очень мало и я реально не совсем понимаю как именно это может а) помочь джуну вообще с си++ б) помочь джуну именно с тем об чём я говорю

вот например я быстренько пролистал до написанного на доске «PIMPL and copy optimization» и что? толку никакого люди сидят и просто делают pimpl везде просто как принцип ну вот у них где-то было такое правило «делать pimpl» я уже не допрашиваюсь почему )) наверное потому что там люди а с людями мне уже не интересно я не эксперт по людям ну по крайней мере в классическом контексте «у нас договор я не торгую семечками они не дают взаймы»

но я смотрю дискуссия зашла в тупик потому я останавливаю

здесь «идеология» в том что не нужно знать что там внутри достаточно просто делать по правилам и оно будет работать

По мне, с такой идеологией в C++ делать нечего.

но нюанс тут ещё и в том что человек может знать и про алгоритмы и про циклы но никак их не сопоставлять от слова вообще просто потому что идеология этого именно _не_ подразумевает

Я понял тебя.
Опять же, слишком разный у нас с тобой опыт в этом плане. Лично я таких вот людей, которые настолько не умеют систематизировать свои знания, хотя по отдельности темы вроде как понимают, встречал очень редко. И то, это были совсем зелёные джуны, которые со временем раздуплялись и начинали проявлять более глубокое понимание.

я практически не слушаю и не смотрю всех этих выступлений реального очень мало и я реально не совсем понимаю как именно это может а) помочь джуну вообще с си++ б) помочь джуну именно с тем об чём я говорю

Конкретно этот доклад — джуну — точно никак.
Другие по пункту a) могут помочь. Смотря что за доклады. Джунам я бы рекомендовал слушать лекции Майерса и Саттера.

Просто в інших мовах ця парадигма виглядає більш красиво.
Наприклад на rust це буде щось таке.
vec.iter_mut().take_while(|i| **i <= 5).for_each(|i| *i *= 10);
(щоправда і там намудрили з посиланнями на посилання). Ну а на хрестах — як завжди.

Ну а з іншого боку в плюсах algorithms це must use і якийсь умовний find_if з лямбдою буде мати набагато більше семантичного значення ніж ручний for-цикл.
std::for_each звичайно доволі нішева функція і на практиці я її використовую тільки якщо це буде лаконічний однострічник.

Просто в інших мовах ця парадигма виглядає більш красиво.
Наприклад на rust це буде щось таке.
vec.iter_mut().take_while(|i| **i <= 5).for_each(|i| *i *= 10);
(щоправда і там намудрили з посиланнями на посилання). Ну а на хрестах — як завжди.

ок не вопрос )) вопрос как теперь выйти с for_each ? ))

Ну а з іншого боку в плюсах algorithms це must use і якийсь умовний find_if з лямбдою буде мати набагато більше семантичного значення ніж ручний for-цикл.

ок не вопрос )) давай конкретный пример будем т.с. ближе к телу

std::for_each звичайно доволі нішева функція і на практиці я її використовую тільки якщо це буде лаконічний однострічник.

for (i : any_range) { sum += i; }

куда исчо лаконичнее?

но...

ок не вопрос )) давай конкретный пример будем т.с. ближе к телу ))

for (i : any_range) { sum += i; }

куда исчо лаконичнее?

sum = accumulate(any_range, 0);

ну вот видишь и ты сразу же ж ошибся что sum уже был изначально

ок я признаю я сказал уже всё по этому маленькому вопросу который только одна сторона совсем большого но я всё сказал дальше мне уже не интересно ))

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

Если именно в переменной sum что-то уже было, и мы хотим добавить к ней сумму по новому рейнджу, тогда можно вот так:
sum = accumulate(any_range, sum);

Или так:
sum += accumulate(any_range, 0);

ок не вопрос )) вопрос как теперь выйти с for_each ? ))

мій приклад робить те ж саме що написано в статті, а саме множить на 10 всі елементи колекції доки не зустріне елемент більше 5. Виходить з foreach та частина що take_while.

for (i : any_range) { sum += i; }

куда исчо лаконичнее?

Повний приклад буде все ж
int sum = 0; for (i : any_range) { sum += i; }
Проти
auto i = std::accumulate(begin(any_range), end(any_range), 0);

но...

ок не вопрос )) давай конкретный пример будем т.с. ближе к телу ))

Різниця між ручним циклом і алгоритмами STL в тому, що ручний цикл каже тобі як робити, а алгоритм — що робити.

В розгляді даної статті, ручний цикл каже:
— Пройтись циклом по всім елементам колекції
— Якщо елемент більше 5 — вийти з циклу
— Помножити елемент на 10

Використання алгоритму каже:
— Застосувати операцію множення на 10 до всіх елементів колекції доки не зустрінеш елемент більше 5

Різниця тут в основному семантична, але мене приваблює саме факт декларативності при використанні алгоритмів. Ну і це добре коли в тебе foreach в одну стрічку (через це я і кажу що foreach нішевий), але купа алгоритмів замінює простині магії з індексами і подібною шнягою.

Тут вже радили Шона Перента, і я з цією людиною абсолютно погоджуюсь.

На плюсах з модифікацією оригінального контейнера:
ranges::for_each(vec | views::take_while([](auto x){return x <= 5;}), [](auto& x){ x*=10;});
або з лінивими обчисленнями:
auto res = vec | views::take_while([](auto x){return x <= 5;}) | views::transform([](auto x){ return x * 10;});

Підписатись на коментарі