Dangling views/ranges: что это и почему опасно

1. Dangling без магии: что это такое

Когда программист говорит «dangling», он обычно имеет в виду простую ситуацию: у нас есть ссылка/указатель/итератор/view, который смотрит на память, где объекта уже нет. Объект «умер», но мы всё ещё храним «адрес» или «окошко» на него. Это как записать себе номер телефона коллеги на бумажке, а потом коллега сменил номер, переехал и уволился — бумажка осталась, а связь с реальностью исчезла.

В классическом C++ dangling часто случается с указателями и ссылками. В ranges/views dangling чаще всего случается с view, потому что view обычно не хранит данные, а лишь хранит «как до них добраться».

Важно почувствовать: dangling — это не «ошибка компиляции» (хотя иногда стандарт пытается нас защитить). Dangling — это ошибка времени жизни, то есть ошибка того, сколько живут объекты и кто на кого ссылается.

Почему views так легко становятся «висячими»

Views устроены так, что они обычно держат внутри себя «ссылку на источник» (в виде итераторов/сентинелов или обёртки-view на исходный range) и иногда ещё держат предикат/функцию преобразования (лямбду). Они вычисляются лениво: пока вы не начали обходить view (например, в range-for), вычисления как будто «обещаны», но не выполнены.

Это можно представить такой схемой:

Контейнер-владелец (vector<Task>)
        |
        |  view ссылается на владельца
        v
filter_view / transform_view / take_view  (данных не хранит)
        |
        |  обход (for) запускает вычисления
        v
элементы (Task) “появляются” по одному при итерации

И вот где ловушка: если контейнер-владелец исчез или поменялся «структурно», view продолжает пытаться ходить по старой реальности.

Учебный контекст: мини‑TaskBoard

Чтобы примеры были не «про сферических int в вакууме», продолжим учебный контекст: у нас есть список задач. Мы не строим архитектуру приложения (это отдельная тема), а просто держим в main() данные и работаем с ними.

#include <string>

enum class Status { Todo, Done };

struct Task {
    int id{};
    std::string title;
    Status status{Status::Todo};
};

Дальше в разных примерах будем фильтровать задачи по статусу, делать view и смотреть, где оно может стать dangling.

2. Сценарий №1: view построен на временном объекте

Самый частый «сюрприз» новичка: мы построили view от временного контейнера, контейнер исчез в конце выражения, а view остался.

Смотрите внимательно: вот контейнер создаётся временно прямо в выражении.

#include <iostream>
#include <ranges>
#include <vector>

int main() {
    auto done_view = std::vector<int>{1, 2, 3, 4}
        | std::views::filter([](int x) { return x % 2 == 0; });

    for (int x : done_view) {
        std::cout << x << ' '; // UB: view ссылается на уже уничтоженный vector
    }
}

Этот код может:

• «работать» на вашей машине (что особенно опасно: вы поверите, что всё ок),
• падать,
• печатать мусор,
• вести себя по‑разному в Debug/Release.

Причина простая: временный std::vector<int>{...} живёт до конца полного выражения (до ;). После ; он уничтожается. А done_view — переменная, которая живёт дальше. Значит, done_view смотрит на уже разрушенный вектор.

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

#include <iostream>
#include <ranges>
#include <vector>

int main() {
    std::vector<int> v{1, 2, 3, 4};
    auto evens = v | std::views::filter([](int x) { return x % 2 == 0; });

    for (int x : evens) {
        std::cout << x << ' '; // 2 4
    }
}

4. Сценарий №2: view «убежал» из функции

Второй классический сценарий: мы создали view внутри функции, где владелец — локальная переменная, и вернули view наружу. Снаружи view живёт, а владелец уже умер.

Представьте «удобную» функцию: «дай мне view всех выполненных задач». Новичок очень легко пишет так:

#include <ranges>
#include <vector>

auto make_done_view_bad() {
    std::vector<int> v{1, 2, 3, 4};
    return v | std::views::filter([](int x) { return x % 2 == 0; });
}

С виду красиво. Но v уничтожится при выходе из функции, и возвращаемый view станет dangling.

Правильный вариант зависит от цели. Если вы хотите именно view (ленивый, без копий), то владелец должен прийти снаружи: например, передать контейнер по ссылке и вернуть view, который ссылается на этот внешний контейнер.

#include <ranges>
#include <vector>

auto done_view_of(const std::vector<int>& v) {
    return v | std::views::filter([](int x) { return x % 2 == 0; });
}

Теперь ответственность честная: кто передал контейнер — тот и обеспечивает, что контейнер живёт дольше, чем view.

И вот так это безопасно используется:

#include <iostream>
#include <ranges>
#include <vector>

auto done_view_of(const std::vector<int>& v) {
    return v | std::views::filter([](int x) { return x % 2 == 0; });
}

int main() {
    std::vector<int> v{1, 2, 3, 4};
    auto evens = done_view_of(v);

    for (int x : evens) std::cout << x << ' '; // 2 4
}

5. Сценарий №3: источник жив, но вы его модифицировали

Теперь более тонкая ситуация. Контейнер‑владелец вроде бы жив, но мы его структурно модифицировали, и из‑за этого view стал опасен.

Для std::vector два главных «врага стабильности ссылок»:

• push_back() может сделать перевыделение (reallocation) и переместить элементы в другое место памяти,
• erase() сдвигает элементы, инвалидирует итераторы и ссылки на элементы после точки удаления.

Вот пример, где всё выглядит логично: мы сделали view на чётные элементы, потом дописали в вектор ещё один элемент, а потом решили обойти view.

#include <iostream>
#include <ranges>
#include <vector>

int main() {
    std::vector<int> v{1, 2, 3, 4};
    auto evens = v | std::views::filter([](int x) { return x % 2 == 0; });

    v.push_back(6); // может вызвать reallocation

    for (int x : evens) {
        std::cout << x << ' '; // потенциально UB
    }
}

Почему «потенциально»? Потому что если push_back не вызвал перевыделение (например, capacity хватило), то может «прокатить». А если вызвал — view/итераторы, на которые он опирается, становятся невалидными. И снова лотерея.

Та же история с erase():

#include <ranges>
#include <vector>

int main() {
    std::vector<int> v{10, 20, 30, 40};
    auto big = v | std::views::filter([](int x) { return x >= 30; });

    v.erase(v.begin()); // сдвиг элементов

    (void)big; // big теперь небезопасно обходить
}

Ключевая мысль: view — это не «снимок данных», а «окно в контейнер прямо сейчас». Если вы меняете контейнер, окно может треснуть.

6. Сценарий №4: лямбда захватила ссылку и «пережила» переменную

Ещё один «любимчик»: view хранит внутри себя лямбду‑предикат. А лямбда может хранить внутри себя ссылки, если вы захватывали [&] или [&threshold].

Сначала безопасный вариант: захват по значению. Это как сделать копию числа threshold внутрь предиката.

#include <ranges>
#include <vector>

int main() {
    std::vector<int> v{5, 10, 15, 20};
    int threshold = 12;

    auto above = v | std::views::filter([threshold](int x) { return x > threshold; });
    (void)above;
}

А теперь опасный: захват по ссылке и «жизнь» view дольше, чем жизнь переменной.

#include <iostream>
#include <ranges>
#include <vector>

int main() {
    std::vector<int> v{5, 10, 15, 20};

    auto make_view = [&]() {
        int threshold = 12;
        return v | std::views::filter([&threshold](int x) { return x > threshold; });
    };

    auto view = make_view(); // threshold умер
    for (int x : view) {
        std::cout << x << '\n'; // UB
    }
}

Ирония в том, что проблема тут даже не в ranges, а в обычном правиле времени жизни ссылок. Просто в ranges это встречается чаще, потому что предикаты часто пишут «на ходу», и рука сама тянется к [&].

7. std::ranges::dangling и модель времени жизни

Что такое std::ranges::dangling

Стандартная библиотека понимает, что возвращать итератор на временный объект — это почти гарантированная беда. Поэтому для некоторых std::ranges‑алгоритмов существует специальный «маркерный» тип std::ranges::dangling. Он означает: «я не могу безопасно вернуть итератор, потому что входной range был временным».

Примерно так это выглядит на практике:

#include <algorithm>
#include <ranges>
#include <vector>

int main() {
    auto it = std::ranges::find(std::vector<int>{1, 2, 3}, 2);
    (void)it; // это может быть std::ranges::dangling, а не нормальный итератор
}

Важно не перепутать: std::ranges::dangling чаще всплывает в теме «алгоритмы и их возвращаемые значения». А наша сегодняшняя боль — это dangling view, который компилятор зачастую не может «запретить» (потому что технически тип корректный), но по времени жизни он уже «не привязан к реальности».

То есть std::ranges::dangling — это попытка стандарта сказать вам: «Я вижу проблему заранее». Но view‑dangling стандарт не всегда может вычислить на этапе компиляции, потому что источник данных и время жизни часто зависят от логики программы.

Практичная модель времени жизни для view

Если вы хотите реально перестать ловить эти баги, полезно держать в голове очень приземлённую модель: у каждого view есть владелец (контейнер или другой владеющий объект), и view — это как «провод» к этому владельцу. Пока владелец на месте и не «переподключался» (не происходили опасные структурные изменения), провод работает. Как только владелец исчез или переехал, провод остаётся, но ведёт в пустоту.

Отсюда рождаются рабочие привычки.

Если вы видите view, созданный из выражения с временным контейнером, остановитесь и спросите себя: «А контейнер точно будет жить до момента, когда я начну обход?» Если вы видите лямбду с [&] внутри view, остановитесь и спросите: «Переменные, на которые я ссылаюсь, переживут этот view?» Если вы видите, что после создания view код продолжает делать push_back/erase, остановитесь и спросите: «Я случайно не строю “окно”, а потом не переставляю стены дома?»

В качестве «правила на ладони» (не как строгий закон стандарта, а как дисциплина кода) можно сформулировать так: view хорошо работает, когда он живёт недолго и используется рядом с местом, где создан, а владелец данных при этом стабилен. Чем дальше view «уезжает» от источника и чем больше вокруг мутаций контейнера, тем выше шанс, что вы играете в UB‑рулетку.

8. TaskBoard: фильтрация задач без выстрела в ногу

Сделаем маленький, но показательный пример на задачах. Пусть у нас есть tasks, и мы хотим показать выполненные.

#include <iostream>
#include <ranges>
#include <vector>

enum class Status { Todo, Done };

struct Task {
    int id{};
    std::string title;
    Status status{Status::Todo};
};

int main() {
    std::vector<Task> tasks{
        {1, "Read ranges paper", Status::Todo},
        {2, "Fix dangling bug", Status::Done},
        {3, "Drink tea", Status::Done},
    };

    auto done = tasks | std::views::filter([](const Task& t) {
        return t.status == Status::Done;
    });

    for (const Task& t : done) {
        std::cout << t.id << ": " << t.title << '\n';
        // 2: Fix dangling bug
        // 3: Drink tea
    }
}

Здесь всё безопасно, потому что:

• tasks — владелец — живёт весь main,
• после создания done мы не делаем push_back/erase,
• лямбда ничего не захватывает по ссылке.

А вот так мы сами себе ставим ловушку (практически незаметную):

#include <ranges>
#include <vector>

auto done_tasks_bad() {
    std::vector<Task> tasks{{1, "Local task", Status::Done}};
    return tasks | std::views::filter([](const Task& t) { return t.status == Status::Done; });
}

Это «красивое» возвращение view на самом деле возвращает проблему.

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

#include <ranges>
#include <vector>

auto done_tasks_of(const std::vector<Task>& tasks) {
    return tasks | std::views::filter([](const Task& t) { return t.status == Status::Done; });
}

Здесь контракт честный: вызывающий код обязан держать tasks живым дольше, чем он использует view.

9. Типичные ошибки

Ошибка №1: строить view от временного контейнера «в одну строку».
Очень легко написать auto x = std::vector<int>{...} | views::filter(...), потому что это выглядит как «функциональный стиль». Но временный контейнер уничтожится в конце выражения, а view останется. Если хочется pipe‑красоты — сначала сохраняйте контейнер в переменную, а потом стройте view.

Ошибка №2: возвращать view из функции, где владелец данных локальный.
Это тот же dangling, только упакованный «в красивый API». Локальный std::vector или std::string умирают при выходе из функции, а возвращённый view продолжает ссылаться на них. Если вы возвращаете view, владелец должен жить снаружи: обычно это означает, что владелец передаётся в функцию по ссылке.

Ошибка №3: захватывать [&] в filter/transform, а потом хранить view дольше, чем живут захваченные переменные.
Захват по ссылке кажется удобным, но это «скрытая ссылка», которая живёт внутри лямбды, которая живёт внутри view. В итоге вы получаете dangling, который выглядит как «обычный фильтр». Если значение маленькое (порог, флаг, id) — чаще безопаснее захватывать по значению.

Ошибка №4: модифицировать std::vector после создания view и думать, что view — это снимок.
View — это не копия и не snapshot. Если после создания view вы делаете push_back или erase, вы рискуете инвалидировать то, на что view опирается. Особенно неприятно то, что иногда «везёт» и всё работает, а потом при другом размере данных внезапно ломается.

Ошибка №5: воспринимать std::ranges::dangling как решение всех проблем времени жизни.
std::ranges::dangling — это защитный маркер в основном для результатов ranges‑алгоритмов (когда нельзя вернуть итератор на временный range). Но dangling‑view может спокойно скомпилироваться и не дать вам никакого «предупреждающего типа». Здесь спасает только дисциплина времени жизни и понимание, кто владеет данными.