Algorithms and Ranges

Common algorithms

std::sort(values.begin(), values.end());
auto it = std::find(values.begin(), values.end(), 42);
int count = std::count(values.begin(), values.end(), 0);
std::reverse(values.begin(), values.end());

Transform and copy

std::vector<int> doubled(values.size());
std::transform(values.begin(), values.end(), doubled.begin(),
               [](int x) { return x * 2; });

Predicates

bool any_negative = std::any_of(values.begin(), values.end(),
                                [](int x) { return x < 0; });

C++20 ranges

namespace views = std::views;
auto even_squares = values
    | views::filter([](int x) { return x % 2 == 0; })
    | views::transform([](int x) { return x * x; });

Important ideas

• Algorithms operate on iterator ranges
• Prefer algorithms over handwritten loops for intent clarity
• Ranges compose lazy views

Best-practice reminders

• Keep predicates pure when possible.
• Watch iterator invalidation after container modifications.
• Use std::span or ranges for non-owning access patterns.

Common ranges algorithms

auto pos = std::ranges::find(values, 42);
std::ranges::sort(values);
auto sum = std::accumulate(values.begin(), values.end(), 0);

• std::ranges::* algorithms accept ranges directly.
• Many support projections, which let you sort or search by a member without handwritten lambdas.

Projections

struct User { std::string name; int score; };

std::ranges::sort(users, std::greater<>{}, &User::score);

Lazy views vs materialized results

auto active_names = users
    | std::views::filter([](const User& user) { return user.score > 0; })
    | std::views::transform([](const User& user) { return user.name; });

• Views do not own elements.
• Materialize with std::vector when you need stable storage or repeated traversal over a changing source.

Quick decision guide

• use classic algorithms when you already have iterators and want a direct one-step operation
• use std::ranges::* algorithms when you already have a range object and want cleaner call sites or projections
• use views when you want cheap composition without immediate allocation
• materialize when the pipeline result needs ownership, caching, or multiple passes

Common composition pattern

struct User {
    std::string name;
    int score;
};

auto top_names = users
    | std::views::filter([](const User& user) { return user.score >= 90; })
    | std::views::transform([](const User& user) { return user.name; });

That shape is the common ranges pipeline: filter first, project second, and only materialize if the calling code needs owned strings or repeated traversal.

Materialize-at-boundary habit

std::vector<std::string> names;
for (const auto& name : top_names) {
    names.push_back(name);
}

Keep the lazy pipeline inside one stage of the program, then materialize right before you cross into storage, caching, or an API that expects owned values.