17370845950

用 std::vector 替代裸数组可消除静态边界失控风险，其 at() 提供边界检查，std::span 则安全传递只读视图并绑定长度与数据，二者配合可堵住多数缓冲区溢出漏洞。

用 std::vector 替代裸数组，彻底消除静态边界失控

风险

裸数组（如 int arr[10]）在传参或计算下标时完全不检查长度，arr[15] = 42 是未定义行为，编译器不会报错，运行时可能静默覆盖相邻内存。而 std::vector 把长度和数据绑定在一起，且提供安全访问接口：

• vec.at(i) 带边界检查，越界抛 std::out_of_range 异常（调试期立刻暴露问题）
• vec[i] 不检查——但你本就不该在不确定索引合法性时直接用它
• 构造/扩容由容器管理，避免手动 new[] + 忘记 delete[] 导致的堆溢出

示例：下面这段代码在越界时会崩溃并给出明确错误位置，而不是悄无声息地破坏其他变量：

std::vector data(5);
try {
    data.at(10) = 99; // 抛 std::out_of_range
} catch (const std::out_of_range& e) {
    // 处理错误
}

用 std::span 安全传递“只读视图”，切断原始缓冲区暴露

函数参数若接收裸指针+长度（如 void process(int* p, size_t n)），调用方极易传错长度或指针指向栈内存已释放区域；std::span 将指针和长度捆绑为不可拥有、仅引用的视图，且支持编译期长度推导：

• std::span s{vec} 自动取 vec.size()，无需手写长度参数
• std::span 可写，但无法延长底层存储——写越界仍会触发 UB，但至少长度不会传错
• 传入局部数组时，std::span 不延长其生命周期，避免悬垂引用（这点比 std::string_view 对 C 字符串更严格）

对比错误写法：

// 危险：长度可能写错，或 ptr 指向临时对象
process(arr, 8); // 实际 arr 只有 5 元素
// 安全：长度与数据强绑定
std::span view{arr}; // 编译期推导为 span
process(view);

警惕 std::span 的生命周期陷阱和隐式转换

std::span 本身不管理内存，只持有一个指针+长度。如果它引用的原始容器提前析构，span 就变成悬垂视图，后续访问仍是未定义行为——这和裸指针一样危险，只是发生条件更隐蔽：

• 不要从函数返回 std::span 指向局部变量（如 return std::span{local_arr}）
• 避免用 std::span 包装 std::vector::data() 后再让 vector resize() 或 clear() —— data 地址可能失效
• std::span 可隐式转成 std::span，但反向不行；传参时优先声明为 const 版本，减少误写风险

典型错误：

std::span bad_span() {
    std::vector temp = {1,2,3};
    return std::span{temp}; // ❌ temp 析构后 span 悬垂
}

混合使用时的边界对齐：确保 std::span 长度 ≤ std::vector::size()

虽然 std::span 可以由任意指针+长度构造，但若你用 vec.data() 和 vec.size() 构造 span，必须保证两者同步。常见疏漏是 vector 被修改后未更新 span：

• vector push_back() 后，旧 span 的长度没变，但底层内存可能已重分配，原 span 失效
• 用 std::span{vec} 初始化比用 std::span{vec.data(), N} 更安全——前者依赖 vector 当前状态，后者硬编码长度易过期
• 若需固定子范围（如处理前 3 个元素），用 std::span{vec}.first(3)，而非手算指针偏移

正确做法：

std::vector buf(100);
// 每次需要视图时动态构造，不缓存 span 对象
auto view = std::span{buf}.first(10); // 明确取前 10 个
process(view);

真正关键的不是用了什么类型，而是是否让长度和数据在逻辑上不可分离——std::vector 管存储生命周期，std::span 管访问边界，二者配合才能堵住大多数缓冲区溢出入口。最容易被忽略的是 span 的生命周期必须短于其所引用的容器，这点没有编译器帮你检查。