Краткий ответ

Используйте std::ranges::to из C++23. Он проходит по диапазону, вычисляет его элементы и материализует результат в контейнер указанного типа, после чего результат больше не зависит от исходного ленивого конвейера.

Исторический контекст

Views из библиотеки ranges обычно являются ленивыми представлениями: они описывают преобразование или отбор элементов, но не создают отдельное хранилище. До C++23 преобразование такого диапазона в контейнер часто требовало явного вызова конструктора контейнера, вставки через итераторы или написания вспомогательной функции.

std::ranges::to появился как стандартный идиоматичный способ завершить конвейер операцией материализации. Он отделяет построение вычисления от решения о том, когда и куда сохранять результат.

Постановка проблемы

Ленивый диапазон может зависеть от исходного контейнера, функции-преобразователя или другого состояния. Если передать такой view дальше, вычисления будут выполняться при обходе, а результат не будет автоматически сохранён.

Неверное решение возникает, когда разработчик ожидает от view поведения обычного контейнера: независимого владения элементами, стабильного результата и возможности использовать его после уничтожения источника. Для этих свойств нужен новый контейнер, а не очередной адаптер диапазона.

Подробное решение

std::ranges::to<Container> принимает диапазон и строит объект Container, добавляя в него вычисленные элементы. Например:

#include <ranges>
#include <string>
#include <vector>

int main() {
    std::vector<std::string> source{"one", "two"};
    auto result = source
        | std::views::transform([](const std::string& s) {
              return s.size();
          })
        | std::ranges::to<std::vector>();
}

В примере transform остаётся ленивым до момента обхода внутри std::ranges::to. Затем создаётся самостоятельный std::vector со значениями типа std::size_t, выведенными из элементов диапазона.

Тип контейнера можно указать с параметрами, например std::ranges::to<std::vector<int>>(). Если параметры шаблона контейнера можно вывести из диапазона и доступных конструкторов, допустима более краткая форма с std::vector.

После материализации изменения исходного контейнера не изменяют уже созданный результат. Однако это не означает, что элементы всегда копируются: конкретные операции зависят от типов элементов, доступных конструкторов и возможностей перемещения.

std::ranges::to не устраняет стоимость вычисления и выделения памяти. Напротив, он намеренно переводит ленивое вычисление в eager-режим и обычно требует хранения всех полученных элементов. Поэтому его не следует добавлять в середину конвейера без необходимости.

Ограничения задаются требованиями к контейнеру и элементам: контейнер должен быть пригоден для построения из диапазона или для добавления в него элементов, а значения диапазона должны быть совместимы с элементным типом. Поддержка C++23 ranges-функций зависит от версии стандартной библиотеки, даже если компилятор умеет включать режим C++23.

Ситуация из практики

Сервис фильтрует большой список записей и передаёт результат в функцию, которая должна владеть данными независимо от исходного буфера. Рассматривались три варианта: вернуть view, вручную заполнить контейнер циклом или завершить конвейер через std::ranges::to.

Возврат view сохраняет ленивость, но оставляет зависимость от времени жизни источника. Ручной цикл даёт полный контроль, но дублирует инфраструктурный код и хуже выражает намерение. Выбран std::ranges::to<std::vector<Record>>(): граница владения явно видна в коде, источник можно безопасно уничтожить, а фильтрация выполняется ровно при построении результата.

Что кандидаты часто упускают

Вопрос: Останется ли результат std::ranges::to ленивым view?

Ответ: Нет. std::ranges::to материализует диапазон в контейнер и выполняет вычисления во время построения результата. Сам контейнер хранит элементы, а не описание исходного конвейера.
Вопрос: Гарантирует ли std::ranges::to отсутствие копирований элементов?

Ответ: Нет. Он выбирает доступные операции построения и вставки, поэтому возможны копирование, перемещение или создание элемента из результата преобразования. Отсутствие лишних копирований зависит от типов, категории диапазона и реализации контейнера; сам факт использования to такой гарантии не даёт.
Вопрос: Когда материализация через std::ranges::to ухудшает решение?

Ответ: Она может увеличить пиковое потребление памяти и заставить вычислить элементы, которые фактически не будут использованы. Если потребитель умеет работать с диапазоном непосредственно, сохранение view может быть выгоднее. Материализовать следует на границе, где действительно нужны владение, повторный обход или конкретный контейнер.