Advanced Ranges and Views

Build lazy pipelines

auto top_scores = scores
    | std::views::filter([](int score) { return score >= 90; })
    | std::views::transform([](int score) { return score / 10; })
    | std::views::take(5);

Views are lazy and usually cheap to compose.

That means the work happens when you iterate the result, not when you define the pipeline.

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

for (int value : pipeline) {
    std::cout << value << '\n';
}

Projections with algorithms

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

Use projections to avoid small one-off lambdas when sorting or searching by a member.

auto it = std::ranges::find(users, 42, &User::id);

This reads as "find the user whose id is 42" instead of forcing you to write the member access manually.

Views are borrowed, not owned

• A view usually depends on another range staying alive.
• Materialize results into a container when you need stable storage.

Safe materialization at an API boundary

auto visible_names = users
    | std::views::filter(&User::active)
    | std::views::transform(&User::name);

std::vector<std::string> stored_names(visible_names.begin(), visible_names.end());

Do this when the result must survive after the source range changes or disappears.

Useful adaptors

• filter
• transform
• take
• drop
• keys
• values
• split

Common pipeline shapes

Filter, then transform

auto labels = users
    | std::views::filter([](const User& user) { return user.active; })
    | std::views::transform([](const User& user) { return user.name; });

Drop a prefix, then take a window

auto page = values | std::views::drop(offset) | std::views::take(page_size);

Iterate keys or values from a map-like container

for (const auto& key : config | std::views::keys) {
    std::cout << key << '\n';
}

Practical guidance

• Keep pipelines readable; break them across lines.
• Avoid hidden work in predicates.
• Materialize at API boundaries when lifetime would otherwise be ambiguous.

When not to use a view pipeline

• When the pipeline becomes harder to read than a simple loop.
• When you need random access to the transformed result repeatedly.
• When the source lifetime is subtle enough that readers may misuse the resulting view.

Quick pitfall reminder

auto bad_view() {
    return std::vector<int>{1, 2, 3} | std::views::filter([](int x) { return x > 1; });
}

This returns a view over a temporary container, which is exactly the sort of lifetime bug ranges can hide if you are not disciplined.