STL algorithms usually take iterators that point to the collection they operate on. But generally speaking, you want to operate on the entire collection. Consider how you sort a `vector` today. To call `std::sort()`, you pass two iterators marking the beginning and end of the `vector`. That's flexible, but is noisy since much of the time you just want to sort the entire `vector`, but you still have to pass the beginning and end of what to sort.

With ranges, you can call `std::ranges::sort(myVector);`. It is treated as if you had called `std::sort(myVector.begin(), myVector.end());` In range libraries, in addition to taking iterators, STL algorithms can take ranges as parameters. Examples of range algorithms available in `<algorithm>` include `copy`, `copy_n`, `copy_if`, `all_of`, `any_of`, and `none_of`, `find`, `find_if`, and `find_if_not`, `count` and `count_if`, `for_each` and `for_each_n`, `equal` and `mismatch`.

Simplified code that is more readable is great, but the benefits of ranges extend further to making it much easier to filter and transform collections of data, and to compose STL algorithms more easily.

In addition to being a little easier to read, it avoid the memory allocation required for `intermediate` in the non-ranges example.

In the code above, the input is first filtered to just the entries that are divisible by three. The result is combined with a transformation that squares those elements (the ones divisible by three). The '`|`' symbol chains the range view operations together, and is read left to right.

A view is lightweight. Like a range, a view doesn't own the elements it provides access to. The time it takes to copy, move, or assign a view is constant, regardless of how many elements it points to.

Views are composable. In the example above, the view of vector elements that are divisible by three is then combined with the view that squares those elements.

The elements of a view are evaluated lazily. That is, the transformation you apply to yield elements in a view is not evaluated until you ask for an element. For example, if you run the following code in a debugger, and put a breakpoint on the lines `auto divisible_by_three = ...` and `auto square = ...`, you'll see that you hit the first breakpoint as every element is tested for divisibility by three, and then the second breakpoint as the ones that are divisible by three are squared.

A view adaptor provides a view over a range. The range being viewed remains unchanged. The produced view doesn't own any elements. Instead, a view allows you to iterate over the underlying range, but using customized behavior that you specify.

The `<ranges>` library provides many kinds of view adaptors. In addition to the filter and transform views above, there are views that take or skip the first N elements of another view, reverse the order of a view, join views, skip elements of another view until a condition is met, transform the elements of another view, among others.

Range adaptors produce lazily evaluated ranges. That is, you don't incur the cost of transforming every element in the range; only the ones that you access.

Range adaptors can be chained, as shown in the example in this article. And that's where the true power of ranges lies, in the ability to chain various transformations together.

Range algorithms have been introduced that take a range for an argument. `std::ranges::sort(myVector);` is an example.

The range algorithms are lazy, meaning that they operate on the range only when an element is accessed. They can work directly on a container, and are easily composed.

Range-based algorithms are basically iterator-based algorithms where instead of taking two iterators, they take a range, instead.

What you can do with a range depends on the underlying iterator type. Range concepts are named to reflect the traversal category its iterators support.

There are different kinds, or refinements, of ranges, that are codified as concepts. This table lists them, along with the type of container they can be applied to:

j