CodeGym /课程 /C++ SELF /Dangling views/ranges: 是什么以及为何危险

Dangling views/ranges: 是什么以及为何危险

C++ SELF

第 62 级, 课程 2

可用

1. Dangling 无魔法：这是什么

当程序员说 “dangling” 时，通常指一个很简单的情形：我们有一个引用/指针/迭代器/view，它指向的内存中的对象已经不存在。对象“已经死”，但我们仍然保存着“地址”或“窗口”。这就像把同事的电话号码写在纸上，然后同事换号、搬走或离职——纸条还在，但它与现实的连接消失了。

在传统的 C++ 中，dangling 常见于指针和引用。在 ranges/views 场景下， dangling 最常见地发生在 view 上，因为 view 通常不持有数据，而只是保存“如何访问它们”的方式。

重要的是要体会：dangling 不是“编译错误”（尽管有时标准会尝试保护我们）。Dangling 是生命周期错误，也就是说是关于对象活多久以及谁引用谁的错误。

为什么 views 如此容易变成“悬空”

Views 的实现通常在内部保存“源”的引用（以迭代器/哨兵形式或对源 range 的 view 包装）并且有时还保存谓词/转换函数（lambda）。它们是按惰性计算的：在你真正开始遍历 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 指向一个已被破坏的 vector。

正确的思路是：如果你想让 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，然后向 vector 追加了一个元素，之后遍历 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：lambda 捕获引用并“比变量活得更久”

另一个常见陷阱：view 内部保存了谓词 lambda。而 lambda 可能捕获引用，如果你使用了 [&] 或 [&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 的实用生命周期模型

如果你想真正减少这类 bug，记住一个接地气的模型很有帮助：每个 view 都有一个所有者（容器或其他拥有数据的对象），view 就像通向该所有者的“电缆”。只要所有者在，且没有“重新接线”（没有发生危险的结构性修改），电缆就能工作。一旦所有者消失或搬走，电缆仍在，但通向空处。

由此可以形成一些编码习惯。

如果你看到 view 是从含有临时容器的表达式创建的，停下来问自己： “容器在我开始遍历之前肯定还会存在吗？” 如果看到 lambda 在 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，
lambda 未按引用捕获任何内容。

但下面这种写法会给自己埋坑（有时很难察觉）：

#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 会留下来。如果想用管道式写法——先把容器保存到变量，再构建 view。

错误 №2：从拥有局部数据的函数返回 view。
这就是另一种形式的 dangling，但包装成“漂亮的 API”。局部的 std::vector 或 std::string 会在函数返回时销毁，而返回的 view 仍然引用它们。如果返回 view，所有者必须在外部存在：通常需要把所有者以引用传入函数。

错误 №3：在 filter/transform 中使用 [&] 捕获，然后把 view 保存得比被捕获变量活得更久。
按引用捕获看似方便，但它是一个“隐藏的引用”，存在于 lambda 中，lambda 存在于 view 中。结果你得到的 dangling 看起来就像“普通的过滤器”。如果被捕获的是小值（阈值、标志、id）——通常按值捕获更安全。

错误 №4：在创建 view 后修改 std::vector，却以为 view 是快照。
View 不是拷贝也不是 snapshot。如果在创建 view 后调用 push_back 或 erase，你有可能使 view 所依赖的内容失效。特别不幸的是，有时“侥幸通过”，看起来没问题，但在不同数据规模下会突然出错。

错误 №5：把 std::ranges::dangling 视为解决所有生命周期问题的万能药。
std::ranges::dangling 主要是为 ranges 算法的返回结果提供保护（当无法返回对临时 range 的迭代器时）。但 dangling-view 可能照常编译并不会给你任何“警告类型”。这里唯一的拯救是生命周期纪律和对谁拥有数据的清晰理解。

上一课上一课

下一课下一课

TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION