Update: unified format

pull/485/head
Allan Downey 3 years ago
parent e67790e976
commit 2c47b2db70

@ -91,13 +91,13 @@ thread 'main' has overflowed its stack
fatal runtime error: stack overflow fatal runtime error: stack overflow
``` ```
通过 `a.tail` 的调用Rust 试图打印出 `a -> b ->a···` 的所有内容,但是在不懈的努力后,`main` 线程终于不堪重负,发生了[栈溢出](https://course.rs/pitfalls/stack-overflow.html)。 通过 `a.tail` 的调用Rust 试图打印出 `a -> b -> a ···` 的所有内容,但是在不懈的努力后,`main` 线程终于不堪重负,发生了[栈溢出](https://course.rs/pitfalls/stack-overflow.html)。
以上的代码可能并不会造成什么大的问题,但是在一个更加复杂的程序中,类似的问题可能会造成你的程序不断地分配内存、泄漏内存,最终程序会不幸**OOM**,当然这其中的 CPU 损耗也不可小觑。 以上的代码可能并不会造成什么大的问题,但是在一个更加复杂的程序中,类似的问题可能会造成你的程序不断地分配内存、泄漏内存,最终程序会不幸**OOM**,当然这其中的 CPU 损耗也不可小觑。
总之,创建引用并不简单,但是也并不是完全遇不到,当你使用`RefCell<Rc<T>>`或者类似的类型嵌套组合(具备内部可变性和引用计数)时,就要打起万分精神,前面可能是深渊! 总之,创建引用并不简单,但是也并不是完全遇不到,当你使用 `RefCell<Rc<T>>` 或者类似的类型嵌套组合(具备内部可变性和引用计数)时,就要打起万分精神,前面可能是深渊!
那么问题来了? 如果我们确实需要实现上面的功能,该怎么办?答案是使用`Weak`。 那么问题来了? 如果我们确实需要实现上面的功能,该怎么办?答案是使用 `Weak`
## Weak ## Weak
`Weak` 非常类似于 `Rc`,但是与 `Rc` 持有所有权不同,`Weak` 不持有所有权,它仅仅保存一份指向数据的弱引用:如果你想要访问数据,需要通过 `Weak` 指针的 `upgrade` 方法实现,该方法返回一个类型为 `Option<Rc<T>>` 的值。 `Weak` 非常类似于 `Rc`,但是与 `Rc` 持有所有权不同,`Weak` 不持有所有权,它仅仅保存一份指向数据的弱引用:如果你想要访问数据,需要通过 `Weak` 指针的 `upgrade` 方法实现,该方法返回一个类型为 `Option<Rc<T>>` 的值。
@ -112,26 +112,26 @@ fatal runtime error: stack overflow
| `Weak` | `Rc` | | `Weak` | `Rc` |
|--------|-------------| |--------|-------------|
| 不计数 | 引用计数 | | 不计数 | 引用计数 |
| 不拥有所有权 | 拥有值的所有权 | | 不拥有所有权 | 拥有值的所有权 |
| 不阻止值被释放(drop) | 所有权计数归零才能drop | | 不阻止值被释放(drop) | 所有权计数归零,才能 drop |
| 引用的值存在返回Some,不存在返回None | 引用的值必定存在 | | 引用的值存在返回 `Some`,不存在返回 `None ` | 引用的值必定存在 |
| 通过`upgrade`取到`Option<Rc<T>>`,然后再取值 | 通过`Deref`自动解引用,取值无需任何操作 | | 通过 `upgrade` 取到 `Option<Rc<T>>`,然后再取值 | 通过 `Deref` 自动解引用,取值无需任何操作 |
通过这个对比,可以非常清晰的看出`Weak`为何这么弱,而这种弱恰恰非常适合我们实现以下的场景: 通过这个对比,可以非常清晰的看出 `Weak` 为何这么弱,而这种弱恰恰非常适合我们实现以下的场景:
- 持有一个`Rc`对象的临时引用,并且不在乎引用的值是否依然存在 - 持有一个 `Rc` 对象的临时引用,并且不在乎引用的值是否依然存在
- 阻止`Rc`导致的循环引用,因为`Rc`的所有权机制,会导致多个`Rc`都无法计数归零 - 阻止 `Rc` 导致的循环引用,因为 `Rc` 的所有权机制,会导致多个 `Rc` 都无法计数归零
使用方式简单总结下:**对于父子引用关系,可以让父节点通过`Rc`来引用子节点,然后让子节点通过`Weak`来引用父节点**。 使用方式简单总结下:**对于父子引用关系,可以让父节点通过 `Rc` 来引用子节点,然后让子节点通过 `Weak` 来引用父节点**。
#### Weak总结 #### Weak 总结
因为Weak本身并不是很好理解因此我们再来帮大家梳理总结下然后再通过一个例子来彻底掌握。 因为 `Weak` 本身并不是很好理解,因此我们再来帮大家梳理总结下,然后再通过一个例子,来彻底掌握。
`Weak`通过`use std::rc::Weak`来引入,它具有以下特点: `Weak` 通过 `use std::rc::Weak` 来引入,它具有以下特点:
- 可访问,但没有所有权,不增加引用计数,因此不会影响被引用值的释放回收 - 可访问,但没有所有权,不增加引用计数,因此不会影响被引用值的释放回收
- 可由`Rc<T>`调用`downgrade`方法转换成`Weak<T>` - 可由 `Rc<T>` 调用 `downgrade` 方法转换成 `Weak<T>`
- `Weak<T>`可使用`upgrade`方法转换成`Option<Rc<T>>`,如果资源已经被释放,则`Option`的值是`None` - `Weak<T>` 可使用 `upgrade` 方法转换成 `Option<Rc<T>>`,如果资源已经被释放,则 `Option` 的值是 `None`
- 常用于解决循环引用的问题 - 常用于解决循环引用的问题
一个简单的例子: 一个简单的例子:
@ -157,13 +157,13 @@ fn main() {
} }
``` ```
需要承认的是,使用`Weak`让Rust本来就堪忧的代码可读性又下降了不少但是。。。真香因为可以解决循环引用了。 需要承认的是,使用 `Weak` Rust 本来就堪忧的代码可读性又下降了不少,但是。。。真香,因为可以解决循环引用了。
## 使用Weak解决循环引用 ## 使用 Weak 解决循环引用
理论知识已经足够,现在用两个例子来模拟下真实场景下可能会遇到的循环引用。 理论知识已经足够,现在用两个例子来模拟下真实场景下可能会遇到的循环引用。
#### 工具间的故事 #### 工具间的故事
工具间里,每个工具都有其主人,且多个工具可以拥有一个主人;同时一个主人也可以拥有多个工具,在这种场景下,就很容易形成循环引用,好在我们有`Weak`: 工具间里,每个工具都有其主人,且多个工具可以拥有一个主人;同时一个主人也可以拥有多个工具,在这种场景下,就很容易形成循环引用,好在我们有 `Weak`
```rust ```rust
use std::rc::Rc; use std::rc::Rc;
use std::rc::Weak; use std::rc::Weak;
@ -182,8 +182,8 @@ struct Gadget {
} }
fn main() { fn main() {
// 创建一个Owner // 创建一个 Owner
// 需要注意该Owner也拥有多个`gadgets` // 需要注意,该 Owner 也拥有多个 `gadgets`
let gadget_owner : Rc<Owner> = Rc::new( let gadget_owner : Rc<Owner> = Rc::new(
Owner { Owner {
name: "Gadget Man".to_string(), name: "Gadget Man".to_string(),
@ -191,35 +191,35 @@ fn main() {
} }
); );
// 创建工具同时与主人进行关联创建两个gadget他们分别持有gadget_owner 的一个引用。 // 创建工具,同时与主人进行关联:创建两个 gadget他们分别持有 gadget_owner 的一个引用。
let gadget1 = Rc::new(Gadget{id: 1, owner: gadget_owner.clone()}); let gadget1 = Rc::new(Gadget{id: 1, owner: gadget_owner.clone()});
let gadget2 = Rc::new(Gadget{id: 2, owner: gadget_owner.clone()}); let gadget2 = Rc::new(Gadget{id: 2, owner: gadget_owner.clone()});
// 为主人更新它所拥有的工具 // 为主人更新它所拥有的工具
// 因为之前使用了`Rc`,现在必须要使用`Weak`,否则就会循环引用 // 因为之前使用了 `Rc`,现在必须要使用 `Weak`,否则就会循环引用
gadget_owner.gadgets.borrow_mut().push(Rc::downgrade(&gadget1)); gadget_owner.gadgets.borrow_mut().push(Rc::downgrade(&gadget1));
gadget_owner.gadgets.borrow_mut().push(Rc::downgrade(&gadget2)); gadget_owner.gadgets.borrow_mut().push(Rc::downgrade(&gadget2));
// 遍历 gadget_owner的gadgets字段 // 遍历 gadget_owner gadgets 字段
for gadget_opt in gadget_owner.gadgets.borrow().iter() { for gadget_opt in gadget_owner.gadgets.borrow().iter() {
// gadget_opt 是一个 Weak<Gadget> 。 因为 weak 指针不能保证他所引用的对象 // gadget_opt 是一个 Weak<Gadget> 。 因为 weak 指针不能保证他所引用的对象
// 仍然存在。所以我们需要显式的调用 upgrade() 来通过其返回值(Option<_>)来判 // 仍然存在。所以我们需要显式的调用 upgrade() 来通过其返回值(Option<_>)来判
// 断其所指向的对象是否存在。 // 断其所指向的对象是否存在。
// 当然Option为None的时候这个引用原对象就不存在了。 // 当然Option None 的时候这个引用原对象就不存在了。
let gadget = gadget_opt.upgrade().unwrap(); let gadget = gadget_opt.upgrade().unwrap();
println!("Gadget {} owned by {}", gadget.id, gadget.owner.name); println!("Gadget {} owned by {}", gadget.id, gadget.owner.name);
} }
// 在main函数的最后 gadget_owner, gadget1和daget2都被销毁。 // 在 main 函数的最后gadget_ownergadget1 和 daget2 都被销毁。
// 具体是,因为这几个结构体之间没有了强引用(`Rc<T>`),所以,当他们销毁的时候。 // 具体是,因为这几个结构体之间没有了强引用(`Rc<T>`),所以,当他们销毁的时候。
// 首先 gadget1和gadget2被销毁。 // 首先 gadget1 gadget2 被销毁。
// 然后因为gadget_owner的引用数量为0所以这个对象可以被销毁了。 // 然后因为 gadget_owner 的引用数量为 0所以这个对象可以被销毁了。
// 循环引用问题也就避免了 // 循环引用问题也就避免了
} }
``` ```
#### tree数据结构 #### tree 数据结构
```rust ```rust
use std::cell::RefCell; use std::cell::RefCell;
use std::rc::{Rc, Weak}; use std::rc::{Rc, Weak};
@ -276,18 +276,18 @@ fn main() {
``` ```
这个例子就留给读者自己解读和分析,我们就不画蛇添足了 这个例子就留给读者自己解读和分析,我们就不画蛇添足了:
## unsafe解决循环引用 ## unsafe 解决循环引用
除了使用Rust标准库提供的这些类型你还可以使用`unsafe`里的原生指针来解决这些棘手的问题,但是由于我们还没有讲解`unsafe`,因此这里就不进行展开,只附上[源码链接](https://codes.rs/unsafe/self-ref.html), 挺长的需要耐心o_O 除了使用 Rust 标准库提供的这些类型,你还可以使用 `unsafe` 里的原生指针来解决这些棘手的问题,但是由于我们还没有讲解 `unsafe`,因此这里就不进行展开,只附上[源码链接](https://codes.rs/unsafe/self-ref.html), 挺长的需要耐心o_o
虽然`unsafe`不安全,但是在各种库的代码中依然很常见用它来实现自引用结构,主要优点如下: 虽然 `unsafe` 不安全,但是在各种库的代码中依然很常见用它来实现自引用结构,主要优点如下:
- 性能高,毕竟直接用原生指针操作 - 性能高,毕竟直接用原生指针操作
- 代码更简单更符合直觉: 对比下`Option<Rc<RefCell<Node>>>` - 代码更简单更符合直觉: 对比下 `Option<Rc<RefCell<Node>>>`
## 总结 ## 总结
本文深入讲解了何为循环引用以及如何使用`Weak`来解决,同时还结合`Rc`、`RefCell`、`Weak`等实现了两个有实战价值的例子,让大家对智能指针的使用更加融会贯通。 本文深入讲解了何为循环引用以及如何使用 `Weak` 来解决,同时还结合 `Rc`、`RefCell`、`Weak` 等实现了两个有实战价值的例子,让大家对智能指针的使用更加融会贯通。
至此,智能指针一章即将结束(严格来说还有一个Mutex放在多线程一章讲解)而Rust语言本身的学习之旅也即将结束后面我们将深入多线程、项目工程、应用实践、性能分析等特色专题来一睹Rust在这些领域的风采。 至此,智能指针一章即将结束(严格来说还有一个 `Mutex` 放在多线程一章讲解),而 Rust 语言本身的学习之旅也即将结束,后面我们将深入多线程、项目工程、应用实践、性能分析等特色专题,来一睹 Rust 在这些领域的风采。

@ -1,5 +1,5 @@
## 结构体自引用 ## 结构体自引用
结构体自引用在Rust中是一个众所周知的难题而且众说纷纭也没有一篇文章能把相关的话题讲透那本文就王婆卖瓜来试试看能不能讲透这一块儿内容让读者大大们舒心。 结构体自引用在 Rust 中是一个众所周知的难题,而且众说纷纭,也没有一篇文章能把相关的话题讲透,那本文就王婆卖瓜,来试试看能不能讲透这一块儿内容,让读者大大们舒心。
## 平平无奇的自引用 ## 平平无奇的自引用
可能也有不少人第一次听说自引用结构体,那咱们先来看看它们长啥样。 可能也有不少人第一次听说自引用结构体,那咱们先来看看它们长啥样。
@ -12,7 +12,7 @@ struct RefWithinMe<'a> {
pointer_to_value: &'a str, pointer_to_value: &'a str,
} }
``` ```
以上就是一个很简单的自引用结构体,看上去好像没什么,那来试着运行下: 以上就是一个很简单的自引用结构体看上去好像没什么,那来试着运行下:
```rust ```rust
fn main(){ fn main(){
let s = "aaa".to_string(); let s = "aaa".to_string();
@ -23,7 +23,7 @@ fn main(){
} }
``` ```
运行后报错: 运行后报错
```console ```console
let v = SelfRef { let v = SelfRef {
12 | value: s, 12 | value: s,
@ -34,8 +34,8 @@ fn main(){
因为我们试图同时使用值和值的引用,最终所有权转移和借用一起发生了。所以,这个问题貌似并没有那么好解决,不信你可以回想下自己具有的知识,是否可以解决? 因为我们试图同时使用值和值的引用,最终所有权转移和借用一起发生了。所以,这个问题貌似并没有那么好解决,不信你可以回想下自己具有的知识,是否可以解决?
## 使用Option ## 使用 Option
最简单的方式就是使用`Opiton`分两步来实现: 最简单的方式就是使用 `Opiton` 分两步来实现:
```rust ```rust
#[derive(Debug)] #[derive(Debug)]
struct WhatAboutThis<'a> { struct WhatAboutThis<'a> {
@ -54,7 +54,7 @@ fn main() {
} }
``` ```
在某种程度上来说,`Option`这个方法可以工作,但是这个方法的限制较多,例如从一个函数创建并返回它是不可能的: 在某种程度上来说,`Option` 这个方法可以工作,但是这个方法的限制较多,例如从一个函数创建并返回它是不可能的
```rust ```rust
fn creator<'a>() -> WhatAboutThis<'a> { fn creator<'a>() -> WhatAboutThis<'a> {
let mut tricky = WhatAboutThis { let mut tricky = WhatAboutThis {
@ -67,7 +67,7 @@ fn creator<'a>() -> WhatAboutThis<'a> {
} }
``` ```
报错如下: 报错如下
```console ```console
error[E0515]: cannot return value referencing local data `tricky.name` error[E0515]: cannot return value referencing local data `tricky.name`
--> src/main.rs:24:5 --> src/main.rs:24:5
@ -79,9 +79,9 @@ error[E0515]: cannot return value referencing local data `tricky.name`
| ^^^^^^ returns a value referencing data owned by the current function | ^^^^^^ returns a value referencing data owned by the current function
``` ```
其实从函数签名就能看出来端倪,`'a`生命周期是凭空产生的! 其实从函数签名就能看出来端倪,`'a` 生命周期是凭空产生的!
如果是通过方法使用,你需要一个无用`&'a self`生命周期标识一旦有了这个标识代码将变得更加受限你将很容易就获得借用错误就连NLL规则都没用 如果是通过方法使用,你需要一个无用 `&'a self` 生命周期标识,一旦有了这个标识,代码将变得更加受限,你将很容易就获得借用错误,就连 NLL 规则都没用:
```rust ```rust
#[derive(Debug)] #[derive(Debug)]
struct WhatAboutThis<'a> { struct WhatAboutThis<'a> {
@ -107,8 +107,8 @@ fn main() {
} }
``` ```
## unsafe实现 ## unsafe 实现
既然借用规则妨碍了我们,那就一脚踢开: 既然借用规则妨碍了我们,那就一脚踢开
```rust ```rust
#[derive(Debug)] #[derive(Debug)]
struct SelfRef { struct SelfRef {
@ -134,7 +134,8 @@ impl SelfRef {
} }
fn pointer_to_value(&self) -> &String { fn pointer_to_value(&self) -> &String {
assert!(!self.pointer_to_value.is_null(), "Test::b called without Test::init being called first"); assert!(!self.pointer_to_value.is_null(),
"Test::b called without Test::init being called first");
unsafe { &*(self.pointer_to_value) } unsafe { &*(self.pointer_to_value) }
} }
} }
@ -143,13 +144,13 @@ fn main() {
let mut t = SelfRef::new("hello"); let mut t = SelfRef::new("hello");
t.init(); t.init();
// 打印值和指针地址 // 打印值和指针地址
println!("{}, {:p}",t.value(), t.pointer_to_value()); println!("{}, {:p}", t.value(), t.pointer_to_value());
} }
``` ```
在这里,我们在`pointer_to_value`中直接存储原生指针而不是Rust的引用因此不再受到Rust借用规则和生命周期的限制而且实现起来非常清晰、简洁。但是缺点就是通过指针获取值时需要使用`unsafe`代码, 在这里,我们在 `pointer_to_value` 中直接存储原生指针,而不是 Rust 的引用,因此不再受到 Rust 借用规则和生命周期的限制,而且实现起来非常清晰、简洁。但是缺点就是,通过指针获取值时需要使用 `unsafe` 代码。
当然,上面的代码你还能通过原生指针来修改`String`,但是需要将`*const`修改为`*mut`: 当然,上面的代码你还能通过原生指针来修改 `String`,但是需要将 `*const` 修改为 `*mut`
```rust ```rust
#[derive(Debug)] #[derive(Debug)]
struct SelfRef { struct SelfRef {
@ -183,36 +184,36 @@ impl SelfRef {
fn main() { fn main() {
let mut t = SelfRef::new("hello"); let mut t = SelfRef::new("hello");
t.init(); t.init();
println!("{}, {:p}",t.value(), t.pointer_to_value()); println!("{}, {:p}", t.value(), t.pointer_to_value());
t.value.push_str(", world"); t.value.push_str(", world");
unsafe { unsafe {
(&mut *t.pointer_to_value).push_str("!"); (&mut *t.pointer_to_value).push_str("!");
} }
println!("{}, {:p}",t.value(), t.pointer_to_value()); println!("{}, {:p}", t.value(), t.pointer_to_value());
} }
``` ```
运行后输出: 运行后输出
```console ```console
hello, 0x16f3aec70 hello, 0x16f3aec70
hello, world!, 0x16f3aec70 hello, world!, 0x16f3aec70
``` ```
上面的`unsafe`虽然简单好用,但是它不太安全,是否还有其他选择?还真的有,那就是`Pin`。 上面的 `unsafe` 虽然简单好用,但是它不太安全,是否还有其他选择?还真的有,那就是 `Pin`
## 无法被移动的Pin ## 无法被移动的 Pin
Pin在后续章节会深入讲解目前你只需要知道它可以固定住一个值防止该值在内存中被移动。 `Pin` 在后续章节会深入讲解,目前你只需要知道它可以固定住一个值,防止该值在内存中被移动。
通过开头我们知道,自引用最麻烦的就是创建引用的同时,值的所有权会被转移,而通过Pin就可以很好的防止这一点: 通过开头我们知道,自引用最麻烦的就是创建引用的同时,值的所有权会被转移,而通过 `Pin` 就可以很好的防止这一点:
```rust ```rust
use std::marker::PhantomPinned; use std::marker::PhantomPinned;
use std::pin::Pin; use std::pin::Pin;
use std::ptr::NonNull; use std::ptr::NonNull;
// 下面是一个自引用数据结构体,因为slice字段是一个指针, 指向了data字段 // 下面是一个自引用数据结构体,因为 slice 字段是一个指针,指向了 data 字段
// 我们无法使用普通引用来实现因为违背了Rust的编译规则 // 我们无法使用普通引用来实现,因为违背了 Rust 的编译规则
// 因此这里我们使用了一个原生指针通过NonNull来确保它不会为null // 因此,这里我们使用了一个原生指针,通过 NonNull 来确保它不会为 null
struct Unmovable { struct Unmovable {
data: String, data: String,
slice: NonNull<String>, slice: NonNull<String>,
@ -220,7 +221,7 @@ struct Unmovable {
} }
impl Unmovable { impl Unmovable {
// 为了确保函数返回时数据的所有权不会被转移, 我们将它放在堆上, 唯一的访问方式就是通过指针 // 为了确保函数返回时数据的所有权不会被转移,我们将它放在堆上,唯一的访问方式就是通过指针
fn new(data: String) -> Pin<Box<Self>> { fn new(data: String) -> Pin<Box<Self>> {
let res = Unmovable { let res = Unmovable {
data, data,
@ -246,20 +247,20 @@ fn main() {
let mut still_unmoved = unmoved; let mut still_unmoved = unmoved;
assert_eq!(still_unmoved.slice, NonNull::from(&still_unmoved.data)); assert_eq!(still_unmoved.slice, NonNull::from(&still_unmoved.data));
// 因为我们的类型没有实现`Unpin`特征,下面这段代码将无法编译 // 因为我们的类型没有实现 `Unpin` 特征,下面这段代码将无法编译
// let mut new_unmoved = Unmovable::new("world".to_string()); // let mut new_unmoved = Unmovable::new("world".to_string());
// std::mem::swap(&mut *still_unmoved, &mut *new_unmoved); // std::mem::swap(&mut *still_unmoved, &mut *new_unmoved);
} }
``` ```
上面的代码也非常清晰,虽然使用了`unsafe`,其实更多的是无奈之举,跟之前的`unsafe`实现完全不可同日而语。 上面的代码也非常清晰,虽然使用了 `unsafe`,其实更多的是无奈之举,跟之前的 `unsafe` 实现完全不可同日而语。
其实`Pin`在这里并没有魔法,它也并不是实现自引用类型的主要原因,最关键的还是里面的原生指针的使用,而`Pin`起到的作用就是确保我们的值不会被移走,否则指针就会指向一个错误的地址! 其实 `Pin` 在这里并没有魔法,它也并不是实现自引用类型的主要原因,最关键的还是里面的原生指针的使用,而 `Pin` 起到的作用就是确保我们的值不会被移走,否则指针就会指向一个错误的地址!
## 使用ouroboros ## 使用 ouroboros
对于自引用结构体,三方库也有支持的,其中一个就是[ouroboros](https://github.com/joshua-maros/ouroboros),当然它也有自己的限制,我们后面会提到,先来看看该如何使用: 对于自引用结构体,三方库也有支持的,其中一个就是 [ouroboros](https://github.com/joshua-maros/ouroboros),当然它也有自己的限制,我们后面会提到,先来看看该如何使用:
```rust ```rust
use ouroboros::self_referencing; use ouroboros::self_referencing;
@ -286,11 +287,11 @@ fn main(){
} }
``` ```
可以看到,`ouroboros`使用起来并不复杂,就是需要你去按照它的方式创建结构体和引用类型:`SelfRef`变成`SelfRefBuilder`,引用字段从`pointer_to_value`变成`pointer_to_value_builder`,并且连类型都变了。 可以看到,`ouroboros` 使用起来并不复杂,就是需要你去按照它的方式创建结构体和引用类型:`SelfRef` 变成 `SelfRefBuilder`,引用字段从 `pointer_to_value` 变成 `pointer_to_value_builder`,并且连类型都变了。
在使用时,通过`borrow_value`来借用`value`的值,通过`borrow_pointer_to_value`来借用`pointer_to_value`这个指针。 在使用时,通过 `borrow_value` 来借用 `value` 的值,通过 `borrow_pointer_to_value` 来借用 `pointer_to_value` 这个指针。
看上去很美好对吧?但是你可以尝试着去修改`String`字符串的值试试,`ouroboros`限制还是较多的,但是对于基本类型依然是支持的不错,以下例子来源于官方: 看上去很美好对吧?但是你可以尝试着去修改 `String` 字符串的值试试,`ouroboros` 限制还是较多的,但是对于基本类型依然是支持的不错,以下例子来源于官方
```rust ```rust
use ouroboros::self_referencing; use ouroboros::self_referencing;
@ -331,19 +332,19 @@ fn main() {
} }
``` ```
总之使用这个库前强烈建议看一些官方的例子中支持什么样的类型和API如果能满足的你的需求就果断使用它如果不能满足就继续往下看。 总之,使用这个库前,强烈建议看一些官方的例子中支持什么样的类型和 API如果能满足的你的需求就果断使用它如果不能满足就继续往下看。
只能说,它确实帮助我们解决了问题,但是一个是破坏了原有的结构,另外就是并不是所有数据类型都支持:它需要目标值的内存地址不会改变,因此`Vec`动态数组就不适合因为当内存空间不够时Rust会重新分配一块空间来存放该数组这会导致内存地址的改变。 只能说,它确实帮助我们解决了问题,但是一个是破坏了原有的结构,另外就是并不是所有数据类型都支持:它需要目标值的内存地址不会改变,因此 `Vec` 动态数组就不适合因为当内存空间不够时Rust 会重新分配一块空间来存放该数组,这会导致内存地址的改变。
类似的库还有: 类似的库还有
- [rental](https://github.com/jpernst/rental) 这个库其实是最有名的,但是好像不再维护了,用倒是没问题 - [rental](https://github.com/jpernst/rental) 这个库其实是最有名的,但是好像不再维护了,用倒是没问题
- [owning-ref](https://github.com/Kimundi/owning-ref-rs) ,将所有者和它的引用绑定到一个封装类型 - [owning-ref](https://github.com/Kimundi/owning-ref-rs),将所有者和它的引用绑定到一个封装类型
这三个库各有各的特点也各有各的缺陷建议大家需要时一定要仔细调研并且写demo进行测试不可大意。 这三个库,各有各的特点,也各有各的缺陷,建议大家需要时,一定要仔细调研,并且写 demo 进行测试,不可大意。
> rental虽然不怎么维护但是可能依然是这三个里面最强大的而且网上的用例也比较多容易找到参考代码 > rental 虽然不怎么维护,但是可能依然是这三个里面最强大的,而且网上的用例也比较多,容易找到参考代码
## Rc+RefCell或Arc+Mutex ## Rc + RefCell Arc + Mutex
类似于循环引用的解决方式,自引用也可以用这种组合来解决,但是会导致代码的类型标识到处都是,大大的影响了可读性。 类似于循环引用的解决方式,自引用也可以用这种组合来解决,但是会导致代码的类型标识到处都是,大大的影响了可读性。
@ -352,7 +353,7 @@ fn main() {
## 学习一本书:如何实现链表 ## 学习一本书:如何实现链表
最后,推荐一本专门将如何实现链表的书(真是富有Rust特色链表都能复杂到出书了O, O)[Learn Rust by writing Entirely Too Many Linked Lists](https://rust-unofficial.github.io/too-many-lists/) 最后,推荐一本专门将如何实现链表的书(真是富有 Rust 特色链表都能复杂到出书了o_o[Learn Rust by writing Entirely Too Many Linked Lists](https://rust-unofficial.github.io/too-many-lists/)
## 总结 ## 总结

Loading…
Cancel
Save