История изменений

база кодовая без использования std::reduce (std::accumulate), с использованием вместо этого явных циклов — ну такое себе — будешь в ней разбираться очень долго и уныло

Циклы завёрнутые в фолды и “accumulate / reduce” и обмазанные сверху лямбдами простоты не добавляют, вот вообще никак.

а так же вообще порицательно

Короче, я пошёл напрямую к источнику и обсудил это с коллегой являющимся по совместительству комитетчиком и довольно активным контрибьютором в gcc / boost. Как и ожидалось, по его словам нет ни одной причины использовать фолды + лямбды там где range-based for-loops хватает. Это никогда (подчеркну - никогда) не приводит к более быстрому асму, а зачастую - так вообще замедляет. И даже если вам повезло и код не замедлился, как минимум вы нарываетесь на debug-info bloat из-за дополнительных типов сгенерированных для лямбд. И чем больше проект тем более критично всё это становится. И это совсем не тот стиль который эти люди пытаются запромоутить среди app-level devs. И это всё на поверхности, мы ещё даже не начали обсуждать подводные камни связанные с багами конкретных версий конкретных компиляторов. Так что мой вам бесплатный совет: будьте проще, и не создавайте себе проблем на пустом месте - их и без того хватает.

база кодовая без использования std::reduce (std::accumulate), с использованием вместо этого явных циклов — ну такое себе — будешь в ней разбираться очень долго и уныло

Циклы завёрнутые в фолды и “accumulate / reduce” и обмазанные сверху лямбдами простоты не добавляют, вот вообще никак.

а так же вообще порицательно

Короче, я пошёл напрямую к источнику и обсудил это с коллегой являющимся по совместительству комитетчиком и довольно активным контрибьютором в gcc / boost. Как и ожидалось, по его словам нет ни одной причины использовать фолды + лямбды там где range-based for-loops хватает. Это никогда (подчеркну - никогда) не приводит к более быстрому асму, а зачастую - так вообще замедляет. И даже если вам повезло и код не замедлился, как минимум вы нарываетесь на debug-info bloat из-за дополнительных типов сгенерированных для лямбд. И чем больше проект тем более критично всё это становится. И это совсем не тот стиль который эти люди пытаются запромоутить среди app-level devs. И это всё на поверхности, мы ещё даже не начали обсуждать подводные камни связанные с багами конкретных версий конкретных компиляторов. Так что мой вам бесплатный совет - будьте проще, и не создавайте себе проблем на пустом месте, их и без того хватает.

база кодовая без использования std::reduce (std::accumulate), с использованием вместо этого явных циклов — ну такое себе — будешь в ней разбираться очень долго и уныло

Циклы завёрнутые в фолды и “accumulate / reduce” и обмазанные сверху лямбдами простоты не добавляют, вот вообще никак.

а так же вообще порицательно

Короче, я пошёл напрямую к источнику и обсудил это с коллегой являющимся по совместительству комитетчиком и довольно активным контрибьютором в gcc / boost. Как и ожидалось, по его словам нет ни одной причины использовать фолды + лямбды там где range-based for-loops хватает. Это никогда (подчеркну - никогда) не приводит к более быстрому асму, а зачастую - так вообще замедляет. И даже если вам повезло и код не замедлился, как минимум вы нарываетесь на debug-info bloat из-за дополнительных типов сгенерированных для лямбд. И чем больше проект тем более критично всё это становится. И это совсем не тот стиль который эти люди пытаются запромотить среди app-level devs. И это всё на поверхности, мы ещё даже не начали обсуждать подводные камни связанные с багами конкретных версий конкретных компиляторов. Так что мой вам бесплатный совет - будьте проще, и не создавайте себе проблем на пустом месте, их и без того хватает.