简体   繁体   English

为什么Clippy建议传递Arc作为参考?

[英]Why does Clippy suggests passing an Arc as a reference?

I am checking Clippy findings in my code and found that the pedantic rule needless_pass_by_value might be a false positive. 我正在检查我的代码中的Clippy结果,发现迂腐规则needless_pass_by_value可能是误报。

It says that: 它说:

warning: this argument is passed by value, but not consumed in the function body 警告:此参数按值传递,但未在函数体中使用

help: consider taking a reference instead: &Arc<Mutex<MyStruct>> 帮助:考虑改为引用: &Arc<Mutex<MyStruct>>

Since cloning the Arc is only reference counting, moving the Arc should not be bad idea. 由于克隆Arc只是引用计数,因此移动Arc应该不是一个坏主意。 Does it really make any difference in terms of quality and performance to send a reference instead of a value for the Arc ? 发送参考而不是Arc的值,在质量和性能方面是否真的有所不同?

#![warn(clippy::pedantic)]

use std::sync::{Arc, Mutex};

fn main() {
    let my_struct = MyStruct { value: 3 };
    let arc = Arc::new(Mutex::new(my_struct));

    arc_taker(arc.clone());
}

fn arc_taker(prm: Arc<Mutex<MyStruct>>) {
    prm.lock().unwrap().do_something();
}

struct MyStruct {
    value: i32,
}

impl MyStruct {
    fn do_something(&self) {
        println!("self.value: {}", self.value);
    }
}

Playground 操场

Calling arc_taker(arc.clone()) increments the reference count, and returning from arc_taker decrements it again. 调用arc_taker(arc.clone())增加引用计数,并且从arc_taker返回会再次减少它。 This is useless in this case, since the arc variable of main already keeps the Arc alive during the entire call. 在这种情况下,这是无用的,因为mainarc变量已经在整个调用期间使Arc保持活动状态。 A reference to it would already suffice. 对它的引用已经足够了。 No need to bump the reference count up and down. 无需上下颠倒引用计数。

In your specific example, arc_taker doesn't even care that it is managed by an Arc . 在您的具体示例中, arc_taker甚至不关心它是由Arc管理的。 All it cares about is that there is a Mutex to lock , so to make your function less restrictive, just take a &Mutex<MyStruct> instead. 它所关心的只是有一个Mutex可以lock ,所以为了减少你的功能限制,只需要使用&Mutex<MyStruct>

If you wanted to do any Arc -specific things to it, like getting the weak_count or something, taking a &Arc<..> would make sense. 如果你想对它做任何特定于Arc事情,比如获取weak_count或其他东西,那么取一个&Arc<..>会有意义。 If your function would keep a clone of the Arc around, only then it would make sense to take an Arc by value, because then the caller can decide to give you an additional reference to it by calling .clone() (thus bumping the reference count), or to give you ownership of its own Arc (and thus not bumping the reference count). 如果你的函数会保留Arc的克隆,那么只有这样才能获得一个Arc by值,因为然后调用者可以通过调用.clone()来决定给你一个额外的引用(从而撞击引用) count),或者给你自己的Arc所有权(因此不会碰到引用计数)。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

相关问题 发出将可变Arc引用传递给hyper service_fn处理程序的问题 - Issue passing mutable Arc reference to hyper service_fn handler 当使用 ThreadPool 传递带引用的 Arc 时会出现“数据转义 function 主体”错误,传递数据本身的 Arc 工作正常 - When using a ThreadPool passing Arc with reference gives a "data escapes the function body" error, passing Arc of data itself works fine 如果我的模块是公开的,为什么有些剪短的 lints 消失了? - Why are some clippy lints gone if my modules are public? 弧参考场成员 - Arc reference to member of field 为什么将 tokio_postgres::Transaction 作为参考传递要求指示匿名生命周期? - Why does passing tokio_postgres::Transaction as a reference ask to indicate the anonymous lifetime? 为什么电弧<Mutex<T> &gt; 需要 T:同步 + 发送? - Why does Arc<Mutex<T>> require T: Sync + Send? 为什么通过移动捕获弧使我的关闭 FnOnce 不是 Fn - Why does capturing an Arc by move make my closure FnOnce not Fn 为什么 Serde 默认不支持 Rc 和 Arc 类型? - Why does Serde not support Rc and Arc types by default? 为什么 Arc::try_unwrap() 会引起恐慌? - Why does Arc::try_unwrap() cause a panic? 如何通过带有特征的弧作为参考? - How to pass a Arc with a trait as a reference?
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM