了解这种"恒量&"专业化的必要性

Understanding the need for this `const&` specialization

本文关键字：专业化 必要性 恒量 了解      更新时间：2023-10-16

在指南支持库中有一个名为final_action的类(本质上是众所周知的ScopeGuard)。有 2 个独立的便利函数来生成此模板化类：

// finally() - convenience function to generate a final_action
template <class F>
inline final_action<F> finally(const F& f) noexcept
{
return final_action<F>(f);
}
template <class F>
inline final_action<F> finally(F&& f) noexcept
{
return final_action<F>(std::forward<F>(f));
}

(来源：https://github.com/Microsoft/GSL/blob/64a7dae4c6fb218a23b3d48db0eec56a3c4d5234/include/gsl/gsl_util#L71-L82)

第一个有什么需要？如果我们只有第二个(使用转发，又名通用，引用)，它不会做同样的事情吗？

让我们考虑完美转发的版本：

  • 当使用右值调用时，它将返回final_action<F>(static_cast<F&&>(f))。

  • 当用左值调用时，它将返回final_action<F&>(f)。

现在让我们考虑const F&重载：

  • 当同时调用左值或右值时，它将返回final_action<F>(f)。

如您所见，有一个重要的区别：

  • 将非const的左值引用传递给finally将生成一个存储F&的包装器

  • 将constlvalue 引用传递给finally将生成一个存储F的包装器

魔杖盒上的现场示例

我不确定为什么认为有必要使const F&超载。

这是final_action的实现：

template <class F>
class final_action
{
public:
explicit final_action(F f) noexcept : f_(std::move(f)), invoke_(true) {}
final_action(final_action&& other) noexcept 
: f_(std::move(other.f_)), invoke_(other.invoke_)
{
other.invoke_ = false;
}
final_action(const final_action&) = delete;
final_action& operator=(const final_action&) = delete;
~final_action() noexcept
{
if (invoke_) f_();
}
private:
F f_;
bool invoke_;
};

除非我错过了什么，否则即时final_action<F&>并没有真正的意义，因为f_(std::move(f))不会编译。

魔杖盒上的现场示例

所以我认为这应该是：

template <class F>
inline final_action<F> finally(F&& f) noexcept
{
return final_action<std::decay_t<F>>(std::forward<F>(f));
}

最终，我认为 GSL 中finally的实现不正确/不最佳(即冗余，代码重复)。

相关文章：