View Composition and Pipes

In the previous lesson, we introduced the concept of views - lightweight, non-owning wrappers that allow us to transform data lazily. We saw that std::views::transform() generates a proxy iterator that calculates values on demand, saving us from allocating temporary vectors.

Without ranges, we have to nest function calls or manage temporary containers.

1#include <vector>
2#include <algorithm>
3#include <iostream>
4
5void UsingIterators(const std::vector<int>& input) {
6  std::vector<int> temp;
7
8  // Pass 1: Filter
9  std::copy_if(
10    input.begin(), input.end(),
11    std::back_inserter(temp),
12    [](int i){ return i % 2 == 0; }
13  );
14
15  // Pass 2: Transform
16  for(auto& i : temp) i = i * i;
17
18  // Pass 3: Take 3
19  int count = 0;
20  for(int i : temp) {
21    if(count++ >= 3) break;
22    // ...
23  }
24}

This code is terrible for performance. It allocates a temporary vector temp on the heap (slow). It iterates over the data multiple times (bad temporal locality). And it processes all the even numbers, even though we only need the first 3 (wasted work).

Views can save us from this but, if we use the syntax we're accustomed to, we would have to nest the function calls inside each other.

1// The "Onion" Anti-Pattern
2auto result = std::views::take(
3  std::views::transform(
4    std::views::filter(input, is_even), // Innermost logic
5    square // Middle logic
6  ),
7  3 // Outermost logic
8);

Humans read top-to-bottom, but this code executes inside-out. To understand what is happening, you have to dig to the center of the nest (filter) and then mentally unwind the stack to the outside (take).

Worse, this syntax makes it difficult to safely modify the pipeline. Adding a new step requires inserting code in the middle of a bracket soup and balancing the closing parentheses at the end.

To solve this, C++20 adopted one of the most beloved features of Unix shells: the pipe operator |.

With the | operator, we can describe a pipeline in a much friendlier way. We can just describe our algorithm top to bottom - filter, then transform, then take:

1#include <vector>
2#include <iostream>
3#include <ranges>
4
5void UsingViews(const std::vector<int>& input) {
6  // Define the pipeline
7  auto pipeline = input
8    | std::views::filter([](int i){ return i % 2 == 0; })
9    | std::views::transform([](int i){ return i * i; })
10    | std::views::take(3);
11
12  // Execute the pipeline
13  for (int i : pipeline) {
14    // ...
15  }
16}

Our previous implementation using <algorithm> was a traditional top-down, "push" mechanism.

Even though we still read our new <ranges> logic from top-to-bottom, if we want to understand what's going on behind the scenes, we should interpret it as a bottom-up, "pull" mechanism:

1. The loop asks take(3) for an item.
2. take(3) asks transform for an item.
3. transform asks filter for an item.
4. filter pulls from input until it finds an even number.
5. The loop asks for take(3) for the next item...

Once take(3) has received 3 items, it uses the sentinal mechanism to signal the loop to stop. If input had 1,000,000 items, we would stop touching memory after finding the 3rd valid match.

So, aside from being faster/safer to write and easier to read, our modern approach also saves massive amounts of CPU time and memory bandwidth.

Saving and Reusing Views

Our previous example defined the entire pipeline as a series of custom views. However, views can also be saved and shared like any other variable. Below, we define filter, transform, and take as dedicated objects, sharable and composable as needed:

1#include <vector>
2#include <iostream>
3#include <ranges>
4
5void UsingViews(const std::vector<int>& input) {
6  // Create reusable views
7  auto isEven = std::views::filter([](int i){ return i % 2 == 0; });
8  auto square = std::views::transform([](int i){ return i * i; });
9  auto take3 = std::views::take(3);
10  
11  // Compose some views:
12  auto take3squares = square | take3;
13
14  // Compose and execute:
15  for (int i : input | isEven | take3squares) {
16    // ...
17  }
18}

Because of lazy evaluation of views, we can define ranges that are theoretically infinite. The std::views::iota(0) view is an example of this. Every time we ask for a number, it generates the next number in the infinite sequence 0, 1, 2, 3...

We can't store an infinite sequence in a container - we don't have infinite memory. But as a lazy-evaluated view, we don't need to store it - the next number in the sequence can just be generated on demand:

1#include <ranges>
2#include <iostream>
3
4int main() {
5  // Generate infinite numbers starting at 0
6  auto infinite_numbers = std::views::iota(0);
7
8  // Pipe them through logic
9  auto squares = infinite_numbers
10    | std::views::transform([](int i) { return i * i; })
11    | std::views::take(5);
12
13  // Prints: 0 1 4 9 16
14  for (int i : squares) {
15    std::cout << i << " ";
16  }
17}

10 1 4 9 16

It is natural to worry that all these layers - Views, Adaptors, Sentinels, Lambdas - add overhead.

However, modern compilers are incredibly good at "devirtualizing" these abstractions. Because the types are all known at compile time (templates), the compiler can inline the entire pipeline.

When you compile a view-based pipeline, the compiler effectively rewrites it into the raw loop you might have written by hand. You get the safety and readability of high-level abstractions with the raw mechanical speed of low-level C.

This is also still improving over time - <ranges> is a relatively recent addition to the language, with many optimizations still to be found by those working on standard library implementations.

Benchmarking

Remember, if we're working on anything where performance is a concern, we should test our algorithms and theories.

Below, we test three versions of our filter transform take 3 algorithm in the environment we created in our benchmarking environment .

We use the iterator/standard library algorithm approach UsingIterators and the view-based approach UsingViews from before. We also attempt an implementation using a raw, abstraction-free loop:

1#include <benchmark/benchmark.h>
2#include <iostream>
3#include <vector>
4#include <ranges>
5#include <algorithm>
6#include <numeric>
7
8int UsingViews(const std::vector<int>& input) {
9  int sum = 0;
10  auto pipeline = input 
11    | std::views::filter([](int i){ return i % 2 == 0; }) 
12    | std::views::transform([](int i){ return i * i; }) 
13    | std::views::take(3);
14  
15  for (int i : pipeline) {
16    sum += i;
17  }
18  return sum;
19}
20
21int UsingIterators(const std::vector<int>& input) {
22  std::vector<int> temp;
23  temp.reserve(input.size() / 2);
24  
25  // Filter
26  std::copy_if(
27    input.begin(), input.end(),
28    std::back_inserter(temp),
29    [](int i){ return i % 2 == 0; }
30  );
31  
32  // Transform
33  for(auto& i : temp) i = i * i;
34  
35  // Take 3 and sum
36  int sum = 0;
37  int count = 0;
38  for(int i : temp) {
39    if(count++ >= 3) break;
40    sum += i;
41  }
42  return sum;
43}
44
45int UsingLoop(const std::vector<int>& input) {
46  int count = 0;
47  int sum = 0;
48  for (int i : input) {
49    if (i % 2 == 0) {
50      sum += i * i;
51      if (++count == 3) {
52        break;
53      }
54    }
55  }
56  return sum;
57}
58
59static constexpr int N = 10000;
60
61static void BM_UsingViews(benchmark::State& state) {
62  std::vector<int> l(N, 1);
63  
64  for (auto _ : state) {
65    int result = UsingViews(l);
66    benchmark::DoNotOptimize(result);
67  }
68}
69BENCHMARK(BM_UsingViews);
70
71static void BM_UsingIterators(benchmark::State& state) {
72  std::vector<int> l(N, 1);
73  
74  for (auto _ : state) {
75    int result = UsingIterators(l);
76    benchmark::DoNotOptimize(result);
77  }
78}
79BENCHMARK(BM_UsingIterators);
80
81static void BM_UsingLoop(benchmark::State& state) {
82  std::vector<int> l(N, 1);
83  
84  for (auto _ : state) {
85    int result = UsingLoop(l);
86    benchmark::DoNotOptimize(result);
87  }
88}
89BENCHMARK(BM_UsingLoop);

We've filled our input with odd numbers (1) creating the worst case scenario. Our algorithms will be forced to search through the entire array hunting for even numbers that never come.

In this scenario, the abstractions are even better than zero cost on my environment. The C++20 UsingViews variation is comfortably ahead, but both of the standard library implementations have optimized to something less expensive than we implemented with our raw loop:

1------------------------------
2Benchmark                  CPU
3------------------------------
4BM_UsingViews          2431 ns
5BM_UsingIterators      4757 ns
6BM_UsingLoop           6975 ns

In the best case scenario where the first 3 elements are all even and our algorithm can complete quickly, our raw loop takes the lead, but it's close:

1------------------------------
2Benchmark                  CPU
3------------------------------
4BM_UsingViews          6.14 ns
5BM_UsingIterators     12277 ns
6BM_UsingLoop           4.39 ns

Our eager-evaluated UsingIterators algorithm is now wasting time squaring 10,000 even numbers even though the next step in the algorithm is going to discard all but three of them.

In this lesson, we saw how the pipe operator transforms C++ code from a tangled mess of nested calls into a clean, declarative pipeline.

1. Readable Syntax: By using |, code reads left-to-right, matching the logical flow of data processing.
2. The "Pull" Model: We visualized how the pipeline works backwards. The consumer pulls data from the end, triggering a chain reaction up the pipe to fetch the next valid item.
3. Infinite Ranges: We demonstrated that because views are lazy, we can express concepts like "all numbers starting from 0" (std::views::iota) without running out of RAM.

In the next lesson, we will introduce std::ranges::subrange. We will learn how this universal adaptor allows us to wrap legacy raw pointers and iterator pairs into modern views, enabling us to use our flexible, view-based pipelines anywhere we want.