C++ views and pipelines: filter, transform, iota

Over the numbers 1 to 8, the pipeline v | std::views::filter(is_even) | std::views::transform(square) | std::views::take(2) tested six numbers, squared two and printed 4 and 16, and building it ran nothing at all. A viewview: A range that does not own its elements: it refers to elements stored elsewhere or computes them, is cheap to copy, and does its work only while it is iterated, as std::views::filter and std::views::iota do. is a range that usually owns no elements: it refers to elements stored somewhere else, or computes them, and it does its work only when you iterate it.

C++ views combine with | into pipelines. Nothing runs until a loop asks for a value, and then the values come one at a time. std::views::take(n) stops after n values, std::views::iota(1, n + 1) produces the numbers 1 to n without storing them, and C++23’s std::ranges::to<std::vector>() runs a pipeline and stores what it produces. A view that refers to its data does not keep it alive, so it must not outlive the container it reads, the one rule that the compiler cannot always check for you.

A pipeline runs nothing until a loop asks for a value

The figure follows the first value through three views; the program below prints a line at every step:

// Views are lazy: building a pipeline runs nothing, and iterating it pulls one element at a time through every step.
#include <print>
#include <ranges>
#include <vector>

int main() {
    std::vector<int> v{1, 2, 3, 4, 5, 6, 7, 8};

    auto pipeline = v | std::views::filter([](int x) { std::println("  filter {}", x); return x % 2 == 0; })
                      | std::views::transform([](int x) { std::println("  square {}", x); return x * x; })
                      | std::views::take(2);
    std::println("pipeline built; nothing has run yet");

    for (int y : pipeline) std::println("got {}", y);
    std::println("done");
}

from session import run

run("""
clang++ -std=c++23 -Wall -Wextra lazy_pipeline.cpp -o lazy_pipeline && ./lazy_pipeline
g++-16 -std=c++23 -Wall -Wextra lazy_pipeline.cpp -o lazy_pipeline-gcc && ./lazy_pipeline-gcc
""")

$ clang++ -std=c++23 -Wall -Wextra lazy_pipeline.cpp -o lazy_pipeline && ./lazy_pipeline
pipeline built; nothing has run yet
  filter 1
  filter 2
  square 2
got 4
  filter 3
  filter 4
  square 4
got 16
  filter 5
  filter 6
done
$ g++-16 -std=c++23 -Wall -Wextra lazy_pipeline.cpp -o lazy_pipeline-gcc && ./lazy_pipeline-gcc
pipeline built; nothing has run yet
  filter 1
  filter 2
  square 2
got 4
  filter 3
  filter 4
  square 4
got 16
  filter 5
  filter 6
done

Building pipeline printed nothing: the three adaptorsrange adaptor: A function object in std::views, such as filter, transform or take, that takes a range and returns a view of it. Adaptors combine with | into a pipeline: v | std::views::filter(is_even) | std::views::transform(square). only stored the functions they were given and a reference to v. The loop then pulled the values one at a time. Step through the run, one request or one value at a time:

For the first value, the filter read 1, rejected it, read 2 and passed it on; the transform squared it; and only then did the loop print 4. After the second value, the loop still incremented its iterator once more, and that increment made the filter look for the next even number, so it tested 5 and 6 before take reported that it had delivered its two values. Elements 7 and 8 were never read, and no intermediate vector existed at any point. That is what lazylazy evaluation: Doing work only when its result is asked for. A view computes an element when a loop or an algorithm asks for the next one, so building a pipeline runs nothing, and elements that nobody asks for are never computed. means for C++ views: each step does the least work that the next one asks for.

The | is only notation. std::views::filter(v, is_even) is the same view as v | std::views::filter(is_even); the pipe reads better when several steps follow one another. A pipeline without its data is an object too: auto evens_squared = std::views::filter(is_even) | std::views::transform(square); can be applied later to any range, as v | evens_squared, which lets you name a sequence of steps once and reuse it.

iota counts without a container, and ranges::to stores the results

Numbers from iota, filtered, squared and stored:

// A pipeline over numbers that iota generates, turned into a vector with std::ranges::to (C++23).
#include <print>
#include <ranges>
#include <vector>

int main() {
    // iota(1, 11) counts 1, 2, ..., 10 without storing them: the loop counter as a range.
    auto even_squares = std::views::iota(1, 11)
                      | std::views::filter([](int x) { return x % 2 == 0; })
                      | std::views::transform([](int x) { return x * x; });

    std::vector<int> stored = even_squares | std::ranges::to<std::vector>();
    std::println("even squares up to 10: {}", stored);

    // A view is cheap to keep and can be iterated again; each time, it computes the values afresh.
    int sum = 0;
    for (int x : even_squares) sum += x;
    std::println("their sum: {}", sum);

    // An unbounded iota with take: the first five multiples of 7.
    auto sevens = std::views::iota(1) | std::views::transform([](int x) { return 7 * x; }) | std::views::take(5);
    std::println("multiples of 7: {}", sevens | std::ranges::to<std::vector>());
}

from session import run

run("""
clang++ -std=c++23 -Wall -Wextra even_squares.cpp -o even_squares && ./even_squares
g++-16 -std=c++23 -Wall -Wextra even_squares.cpp -o even_squares-gcc && ./even_squares-gcc
""")

$ clang++ -std=c++23 -Wall -Wextra even_squares.cpp -o even_squares && ./even_squares
even squares up to 10: [4, 16, 36, 64, 100]
their sum: 220
multiples of 7: [7, 14, 21, 28, 35]
$ g++-16 -std=c++23 -Wall -Wextra even_squares.cpp -o even_squares-gcc && ./even_squares-gcc
even squares up to 10: [4, 16, 36, 64, 100]
their sum: 220
multiples of 7: [7, 14, 21, 28, 35]

std::views::iota(1, 11) is the half-open range from 1 to 10, the counter of for (int i = 1; i < 11; ++i) as a range. std::views::iota(1) has no end and counts for as long as anyone asks, which take(5) limits to five values. std::ranges::to<std::vector>() (C++23, paper P1206R7) runs a pipeline to its end and builds a vector, deducing the element type, and it worked with both standard libraries. The pipeline even_squares was iterated twice, and each pass computed the values again: a view stores the recipe, not the results. Store the results in a container when you need them more than once and the computation is not cheap.

Other adaptors of C++20 follow the same pattern. std::views::reverse walks a range backwards, std::views::drop(n) skips the first n elements, std::views::take_while(pred) stops at the first element that fails a test, and std::views::keys and std::views::values pick the two halves of the entries of a map.

Keep a view for one pass and a container for results you keep

Three questions about the result decide between them:

Pipelines shine when the data is read once, in one place, while the container it comes from is alive: reports, searches and conversions written as a sentence of steps instead of a loop with temporary vectors. A container is the better choice for results that are kept, returned from a function, shared between threads or read many times.

Views are cheap because they skip the bookkeeping that containers do, and each skipped step has a rule:

• A view that outlives its data. A view returned from a function must not refer to a local container, which is destroyed when the function returns: it would be a dangling viewdangling view: A std::string_view, or another view that owns nothing, whose characters have been destroyed or freed. Reading it is undefined behaviour, which AddressSanitizer reports as a heap-use-after-free when the characters were on the heap. More in “std::string and std::string_view”.
• A remembered first match. A filter view finds its first match once and remembers it, so it cannot be iterated through a const reference.
• Double work. A transform placed before a filter runs twice for every element that passes the filter. C++26’s std::views::cache_latest, in GCC 16 but not yet in Apple clang 21, keeps the last value, so the transform runs once.
• Two passes in ranges::to. Building a vector from a filter view walks the pipeline twice, once to count and once to copy.

Practise: lazy pipelines

The first question comes from the idea your answers show is weakest, and every choice explains what it gets right or wrong.

Views that outlive their data, remembered matches and double work, reproduced Pro: opens with a Pro, Premium or Ultimate pass

Pipelines in practice: ranges::to, measured costs and a report to build Pro: opens with a Pro, Premium or Ultimate pass

Interview questions

Key takeaways

• A view refers to data or computes it, and does its work only while it is iterated, one element at a time.
• | builds pipelines from adaptors such as views::filter, views::transform, views::take and views::iota.
• std::ranges::to<std::vector>() (C++23) runs a pipeline and stores the results.
• A view must not outlive the container it refers to; return containers, not views of locals.