简体   繁体   English

Rust 智能指针 std::rc::Rc 和 std::sync::Arc 分别类似于 C++ 智能指针 std::shared_ptr 和 std::atomic_shared_ptr 吗?

[英]Are Rust smart pointers std::rc::Rc and std::sync::Arc analogous to the C++ smart pointers std::shared_ptr and std::atomic_shared_ptr respectively?

Is there analogy between Rust smart pointers std::rc::Rc and std::sync::Arc with the C++ smart pointers std::shared_ptr and std::atomic_shared_ptr ? Rust 智能指针std::rc::Rcstd::sync::Arc与 C++ 智能指针std::shared_ptrstd::atomic_shared_ptr之间是否存在类比? For me, they look the same, but probably there are some implementation nuances.对我来说,它们看起来一样,但可能存在一些实现上的细微差别。 For example in C++ std::shared_ptr the reference count in the control block is atomic despite the pointer itself is not.例如在 C++ std::shared_ptr中,控制块中的引用计数是原子的,尽管指针本身不是。 Is it the same in Rust's std::rc::Rc ? Rust 的std::rc::Rc中是否相同?

Rust's Arc<T> is largely equivalent to C++'s shared_ptr<T> Rust 的Arc<T>在很大程度上等同于 C++ 的shared_ptr<T>

Both are "smart pointers" that provide shared ownership of a value via reference counting.两者都是“智能指针”,通过引用计数提供值的共享所有权。 They both use atomics for internal operations so that ownership can be tracked between threads safely.它们都将原子用于内部操作,以便可以在线程之间安全地跟踪所有权。

One notable difference is the C++ std::shared_ptr implementation provides an aliasing constructor where you can create a std::shared_ptr<U> for a nested field of a std::shared_ptr<T> such that the std::shared_ptr<U> tracks the root T object properly.一个显着的区别是 C++ std::shared_ptr实现提供了一个别名构造函数,您可以在其中为std::shared_ptr<T>的嵌套字段创建std::shared_ptr<U> ,这样std::shared_ptr<U>正确跟踪根T object。

C++ has no equivalent of Rust's Rc<T> C++ 没有等同于 Rust 的Rc<T>

The only difference between std::rc::Rc and std::sync::Arc is that the internal reference tracking is not atomic. std::rc::Rcstd::sync::Arc之间的唯一区别是内部引用跟踪不是原子的。 This means it cannot be used between threads, but has the benefit of avoiding the potential costs of atomic operations.这意味着它不能在线程之间使用,但可以避免原子操作的潜在成本。

Rust has no equivalent of C++'s atomic<shared_ptr<T>> Rust 没有等同于 C++ 的atomic<shared_ptr<T>>

C++'s std::atomic is generic so its atomic pointer type is a std::atomic<T*> whereas Rust's just has the dedicated type std::sync::atomic::AtomicPtr<T> . C++ 的std::atomic是通用的,所以它的原子指针类型是std::atomic<T*>而 Rust 的只有专用类型std::sync::atomic::AtomicPtr<T> C++ has a specialization for std::atomic<std::shared_ptr<T>> so that multiple threads can atomically access and modify the shared_ptr itself, not just the shared value. C++ 对std::atomic<std::shared_ptr<T>>进行了专门化,以便多个线程可以原子地访问和修改shared_ptr本身,而不仅仅是共享值。 The std::atomic_shared_ptr mentioned by OP was not standardized in favor of this specialization. OP 提到的std::atomic_shared_ptr没有标准化以支持这种专业化。

There may exist libraries for the equivalents but I've only included what's in the respective standard libraries.可能存在等效,但我只包含了相应标准库中的内容。

See also:也可以看看:

For example in C++ std::shared_ptr the reference count in the control block is atomic despite the pointer itself is not.例如在 C++ std::shared_ptr 中,控制块中的引用计数是原子的,尽管指针本身不是。 Is it the same in Rust's std::rc::Rc?在 Rust 的 std::rc::Rc 中是一样的吗?

No. Arc is the analogue to shared_ptr : the reference-counting is atomic (and thus thread-safe), the data is not (which is why you'll usually see Arc<Mutex<T>> or Arc<RwLock<T>> in order to allow mutation of the inner type, otherwise Arc will only provide read-only access).不。 Arc类似于shared_ptr :引用计数是原子的(因此是线程安全的),数据不是(这就是为什么你通常会看到Arc<Mutex<T>>Arc<RwLock<T>>为了允许改变内部类型,否则Arc将只提供只读访问)。

Rc is completely unsynchronised, and in fact statically can not be moved between threads (it's !Send ). Rc是完全不同步的,实际上不能在线程之间静态移动(它是!Send )。 There is no such type in the C++ standard library[0]. C++标准库[0]中没有这个类型。

[0] although libstdc++ will use non-thread-safe shared_ptr if it believes multithreading is not involved, that's more of an optimisation / hack: https://snf.github.io/2019/02/13/shared-ptr-optimization/ [0] 尽管 libstdc++ 认为不涉及多线程时会使用非线程安全的shared_ptr ,但这更像是一种优化/破解: https://snf.github.io/2019/02/13/shared-ptr-optimization /

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

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM