理解这种`const&`专业化的必要性

Bar*_*uch 7 c++ overloading reference c++11 guideline-support-library

在指南支持库中有一个名为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));
}
Run Code Online (Sandbox Code Playgroud)

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

第一个需要什么?如果我们只有第二个(使用转发,也就是通用,引用)它不会做同样的事情吗?

Vit*_*meo 8

让我们考虑完美转发版本:

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

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

我们现在考虑const F&过载:

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

如您所见,有一个重要的区别:

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

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

wandbox上的实例


我不确定为什么认为有必要进行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_;
};
Run Code Online (Sandbox Code Playgroud)

除非我遗漏了某些东西,否则瞬间final_action<F&>没有意义,因为f_(std::move(f))不会编译.

wandbox上的实例

所以我认为这应该是:

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

最终,我认为finallyGSL 中的实现不正确/不理想(即冗余,有代码重复).