C++执行函数foo时如何保证Bar类对象存在，各方案优缺点是什么

现有方案疑问澄清 #

• 传Bar&的悬垂风险是C++原生引用的固有缺陷，语言层面没有强制生命周期检查的机制，这类风险只能靠开发约定或者调试工具（如ASAN）提前发现
• 普通shared_ptr<Bar>默认管理动态存储期对象，但可以通过自定义空删除器适配自动、静态存储期的对象，不过这种用法同样无法避免非动态对象提前销毁的悬垂问题
• 自定义辅助类型不一定是重复造shared_ptr的轮子，针对你的场景可以实现比shared_ptr轻量得多的版本，还能明确参数语义，不算冗余开发

可选方案 #

方案1：统一使用带自定义删除器的std::shared_ptr<Bar> #

对于非动态存储期的bar，可以构造带空删除器的shared_ptr适配：

// 栈上bar的调用示例
Bar bar;
auto sp = std::shared_ptr<Bar>(&bar, [](Bar*){}); // 空删除器，不会释放栈对象
foo(sp);

foo的签名为void foo(std::shared_ptr<Bar> bar_sp)，只要foo内部持有该shared_ptr副本，即可保证动态存储期的bar不会被提前释放。

• 优势：接口统一，不需要额外自定义类型，复用标准库设施
• 局限性：非动态存储期的bar仍存在悬垂风险，需要调用方遵守生命周期约定；存在引用计数维护的轻微性能开销

方案2：自定义轻量生命周期标记类 #

因为foo不需要操作bar，仅需要标记其生命周期，可以实现无额外开销的Guard类型：

class BarLifetimeGuard {
public:
    explicit BarLifetimeGuard(const Bar& b) : bar_ref(b) {}
    BarLifetimeGuard() = delete;
    ~BarLifetimeGuard() = default;
    // 允许复制、移动，符合值语义要求
    BarLifetimeGuard(const BarLifetimeGuard&) = default;
    BarLifetimeGuard(BarLifetimeGuard&&) = default;
    BarLifetimeGuard& operator=(const BarLifetimeGuard&) = default;
    BarLifetimeGuard& operator=(BarLifetimeGuard&&) = default;
private:
    std::reference_wrapper<const Bar> bar_ref;
};

foo的签名改为void foo(BarLifetimeGuard guard, /*其他参数*/)，调用方需要传入绑定了目标bar的Guard实例。

• 优势：开销极低，仅占一个引用的大小，无引用计数开销；参数语义明确，调用方可以清晰感知该参数的生命周期绑定作用；可在调试模式下扩展存活检查逻辑，提前发现悬垂问题
• 局限性：本质和传引用一致，无法完全避免调用方传入绑定了已销毁对象的Guard，仍需遵守开发约定

方案3：调用包装器内置bar构造（仅适用于不需要特定bar实例的场景） #

如果不需要绑定调用方提供的特定bar实例（仅要求存在任意Bar对象，符合你提到的Bar是空对象、foo不需要感知它的特性），可以直接用包装函数绑定生命周期：

template<typename... Args>
decltype(auto) foo_wrapper(Args&&... args) {
    Bar bar; // 包装函数栈上构造，生命周期完全匹配foo执行期
    return foo(std::forward<Args>(args)...);
}

所有对foo的调用都通过foo_wrapper触发即可。

• 优势：完全消除调用方负担，不需要传入任何和Bar相关的参数；100%避免悬垂风险，生命周期完全由包装器控制；无任何额外性能开销
• 局限性：仅适用于不需要特定bar实例的场景，如果逻辑要求必须使用调用方提供的bar则无法使用

方案4：使用std::span<const Bar, 1>传递参数 #

本质和传原生引用一致，但std::span的语义更偏向于“传入的内存段在调用期间合法有效”，比原生引用的语义更清晰，也能避免隐式转换带来的误用。

• 优势：标准库类型，不需要自定义实现，无额外性能开销
• 局限性：仍存在悬垂风险，没有解决原生引用的核心问题

选型建议 #

• 如果必须使用调用方提供的特定bar实例，优先选择方案2的自定义Guard，语义清晰、开销低，还可扩展调试检查能力
• 如果不需要特定bar实例，直接选择方案3，是所有方案中最安全、开发成本最低的选择
• 如果现有项目中已经用shared_ptr管理Bar实例，选择方案1，不需要修改现有管理逻辑

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