将函数返回的共享指针绑定到对值的左值引用是不错的做法？

Question

虽然我花了一段时间才习惯它,但我现在养成了让我的函数通过lvalue-reference const而不是value 来获取共享指针参数的习惯(除非我需要修改原始参数,当然,在这种情况下)我把它们通过左值引用非const):

void foo(std::shared_ptr<widget> const& pWidget)
//                               ^^^^^^
{
    // work with pWidget...
}

这具有避免共享指针的不必要副本的优点,这意味着线程安全地增加引用计数并且可能引起不期望的开销.

现在我一直想知道采用一种有点对称的习惯来检索由函数的值返回的共享指针是否合理,比如下面的代码片段末尾:

struct X
{
    // ...
    std::shared_ptr<Widget> bar() const
    {
        // ...
        return pWidget;
    }
    // ...
    std::shared_ptr<Widget> pWidget;
};

// ...

// X x;
std::share_ptr<Widget> const& pWidget = x.bar();
//                     ^^^^^^

采用这种编码习惯有任何陷阱吗？有没有什么理由我通常会更喜欢将返回的共享指针分配给另一个共享指针对象而不是将它绑定到引用？

Answer 1

这只是重写旧的问题,即捕获对临时的const引用是否比创建副本更有效.简单的答案是它不是.在线:

// std::shared_ptr<Widget> bar();
std::shared_ptr<Widget> const & pWidget = bar();

编译器需要创建一个本地未命名的变量(不是临时的),通过调用来初始化它,bar()然后绑定对它的引用:

std::shared_ptr<Widget> __tmp = bar();
std::shared_ptr<Widget> const & pWidget = __tmp;

在大多数情况下,它将避免创建引用,并在函数的其余部分中仅对原始对象进行别名,但在一天结束时,变量是否被调用pWidget或__tmp别名将不会带来任何好处.

相反,对于不经意的读者来说,它可能看起来bar()不是创建一个对象而是产生一个已经存在的引用std::shared_ptr<Widget>,所以维护者必须找出bar()定义的位置,以了解是否pWidget可以在此范围之外进行更改功能.

通过绑定到const引用的生命周期扩展是语言中的一个奇怪的功能,它几乎没有实际用途(即当引用是基数时,你不太关心值返回的确切派生类型是什么,即ScopedGuard).