Introduction

When developers hit a compile error around boost::equals or boost::range::equal, the message often looks like the range itself "must be copyable." That is usually an oversimplification. In most cases, the real requirement comes from the iterators, adaptors, or callable objects involved in the comparison rather than from the conceptual idea of a range.

What the Algorithm Really Does

At a high level, a range equality algorithm compares two sequences by walking both from begin to end and checking whether corresponding elements match.

That logic looks roughly like this:

1#include <algorithm>
2#include <iostream>
3#include <vector>
4
5int main() {
6    std::vector<int> a{1, 2, 3};
7    std::vector<int> b{1, 2, 3};
8
9    bool same = std::equal(a.begin(), a.end(), b.begin(), b.end());
10    std::cout << std::boolalpha << same << '\n';
11}

Boost range-based helpers are convenience wrappers around this style of iterator comparison. The algorithm needs iterators it can copy, advance, and compare. That is a narrower requirement than "the whole range object must be freely copyable in every situation."

Where the Copyability Requirement Usually Comes From

Standard-library-style algorithms commonly copy iterators and predicates internally. That means a type participating in the algorithm often needs copy construction even if the data source itself is logically just being viewed.

For example:

• iterators are commonly copied as local variables
• predicates or comparison functors are often passed by value
• adapted range objects may store state by value

If one of those pieces is non-copyable, the compiler error can surface at the call to boost::equals, even though the algorithm itself is not trying to duplicate your entire data set.

Adaptors Change the Story

This becomes more visible with adapted ranges. Many Boost range adaptors create lightweight view objects that internally store iterators, predicates, or transformation functions. Those helper objects often need copy semantics because the algorithm copies the adapted range or copies iterators derived from it.

A simplified example with a copyable predicate is fine:

1#include <boost/range/adaptor/filtered.hpp>
2#include <boost/range/algorithm/equal.hpp>
3#include <iostream>
4#include <vector>
5
6struct IsEven {
7    bool operator()(int value) const {
8        return value % 2 == 0;
9    }
10};
11
12int main() {
13    std::vector<int> left{2, 4, 6};
14    std::vector<int> right{2, 4, 6};
15
16    auto left_view = left | boost::adaptors::filtered(IsEven{});
17    auto right_view = right | boost::adaptors::filtered(IsEven{});
18
19    std::cout << std::boolalpha
20              << boost::range::equal(left_view, right_view)
21              << '\n';
22}

If the predicate or stored state were deliberately non-copyable, this kind of pipeline could fail to compile even though the original vectors are perfectly ordinary.

Ranges vs Iterators vs Views

It helps to separate three ideas:

• the underlying container, such as std::vector<int>
• the iterators returned by begin() and end()
• any view or adaptor object wrapped around the container

The container may be stable and easy to work with, but a view can still become non-copyable because it stores a move-only callable or some stateful adapter. When the algorithm copies that view or the iterators derived from it, compilation breaks.

A Practical Mental Model

Instead of thinking "Boost requires ranges to be copyable," think this way: range algorithms expect the participating range machinery to model the iterator and value semantics they need. If your range pipeline introduces move-only state, that assumption can fail.

When debugging:

• test the underlying containers directly first
• remove adaptors temporarily
• replace stateful lambdas or move-only functors with simple copyable structs
• check whether the error mentions iterator construction or stored predicates

Those steps usually isolate the real source quickly.

Common Pitfalls

• Blaming the container when the real problem is a non-copyable adaptor or predicate object.
• Assuming a range view is just a reference wrapper. Many views carry internal state by value.
• Reading template errors too literally. The failure site may be boost::equals, but the violated requirement may belong to an iterator or functor type.
• Mixing move-only modern C++ patterns with older generic libraries that still expect copyable algorithm inputs.

Summary

• 'boost::equals mainly needs algorithm-friendly iterator semantics, not arbitrary copying of your full data set.'
• Compile failures often come from non-copyable iterators, predicates, or adapted views.
• Range adaptors can introduce copyability requirements even when the source container is simple.
• Debug by comparing plain containers first, then reintroducing adaptors step by step.
• Think in terms of the whole range pipeline, not just the final algorithm call.