如何确保构造的Range合法？boost::join与std::views::transform混用遇UB

根源解析 #

你遇到的无效内存访问是**未定义行为（UB）**的直接表现：

• get1b() 和 get2b() 均返回了依赖函数内局部变量的视图。函数执行完毕后，局部变量（如std::array实例、transform视图依赖的底层对象）会被销毁，导致返回的视图成为悬空引用。get1b()看似正常只是巧合，本质上同样存在UB风险。
• 额外隐患：std::views::transform生成的std::string是临时对象，boost::join的视图会间接引用这些临时对象，进一步加剧了悬空引用的概率。

确保Range合法的核心准则 #

• 视图生命周期必须≤底层依赖对象：绝对禁止返回依赖函数内局部变量的视图，局部变量销毁后视图必然失效。
• 物化临时结果：若需基于临时对象构造可安全传递的Range，先将中间结果存入容器（如std::vector、std::string），再返回容器或基于容器的视图（此时容器生命周期由调用者掌控）。
• 避免视图嵌套引用临时对象：当transform生成临时对象时，不可直接传入boost::join，需先物化transform的结果，确保子Range的生命周期稳定。

具体修正方案 #

方案1：返回物化后的最终值（推荐，彻底消除UB） #

将连接后的视图直接转换为std::string返回，既解决悬空引用问题，也能绕过Intellisense的故障：

#include <boost/range/join.hpp>
#include <ranges>
#include <array>
#include <string>

auto get1b() -> std::string {
    const auto rng = std::array{"a", "b", "c"};
    auto str_ranges = rng | std::views::transform([](auto s) {
        return std::string(s);
    });
    return boost::join(str_ranges) | std::ranges::to<std::string>();
}

// get2b()同理修改：将原视图逻辑最终转换为std::string返回

方案2：由调用者管理底层Range（适合需返回视图的场景） #

若必须返回视图，需将底层Range作为参数传入函数，确保其生命周期由调用者控制：

#include <boost/range/join.hpp>
#include <ranges>
#include <array>

template <typename Rng>
auto get1b(Rng&& rng) {
    return boost::join(std::forward<Rng>(rng) | std::views::transform([](auto s) {
        return std::string(s);
    }));
}

// 调用示例：
// std::array arr{"a", "b", "c"};
// auto safe_view = get1b(arr); // arr的生命周期由调用方控制，视图安全

关于std::move(rng)的误区 #

你考虑的return std::move(rng) | ...写法完全无效：rng是函数内的局部变量，即使执行move操作，其生命周期仍局限于函数内部，函数退出后依然会被销毁，返回的视图依然会悬空。

内容的提问来源于stack exchange，提问作者MarkB