Rust常用特型之Drop特型.md在Rust标准库中,存在很多常用的工具类特型,它们能帮助我们写出更具有Rust风格的代码。
今天,我们主要学习Drop
特型。
(注:本文更多的是对《Programing Rust 2nd Edition》的自己翻译和理解,并不是原创)
当一个值不再拥有owner时(在Rust中每个值都有一个owner,并且最多只有一个owner),我们说Rust释放/清理(Drop)了该值。释放一个值通常意味着也需要一并释放它占用的其它资源,例如堆存储。释放可以发生在多种场合:例如变量超出作用域,表达式语句的结尾,截断一个向量并移除末尾的值等。
接下来的内容中,清理和释放表达的是同一个含义,均为drop的意思。
通常情况下,Rust会自动为你清理值。例如如下代码:
struct Appellation {
name: String,
nicknames: Vec<String>
}
这里我们来复习一下Vec
的有关知识。
一个Vec
由三个值构成, 第一个值是指针,它指向在堆上为元素分配的缓冲区。 该缓冲区由Vec
本身拥有。第二值是缓冲区的容量Cap
。第三个值是当前元素的个数length
。它是一个胖指针。当缓冲区的大小达到它的容量时,再增加元素会重新分配一个更大的缓冲区,并将原来的元素复制过去,同时更新向量的指针,容量和长度值,最后释放旧的缓冲区。
一个Appellation
对象即包含了堆上的字符串内容(对应的name字段),又包含了堆上的向量元素缓冲区(对应nicknames
字段)。当这个对象释放时,Rust会小心清理所有资源,并不需要你自己做任何处理。然而,如果你愿意,你也可以通过实现std::ops::Drop
特型来自定义你的类型的清理方式这里为什么有个你的类型呢?因为Rust不允许特型和类型都是外部的,必须有一个是本地的。此时Drop
特型已经是外来的(相对于你的代码),因此类型必须是本地定义的。
Drop特型的定义为:
trait Drop {
fn drop(&mut self);
}
个人理解,未必正确
我们可以看到,该特型仅有一个drop
函数,注意它的参数类型是&mut
,因为我们要做相关清理工作,因此必须是可变的。如果参数是mut self
会怎么样?那么相当于值转移到本函数中了,在本函数处理完毕后该值的owner
就不存在了,此时又到了调用drop
的场景,从而形成无限循环,所以参数类型必定为&mut
。
当一个值被清理时,如果它实现了Drop
特型,那么Rust会自动调用它的drop
方法。该调用发生在清理它的内部元素或者字段之前。这说明用户自定义的drop
函数有第一优先权。当然这种隐匿调用也是调用drop
函数的唯一方式,如果你手动调用它,那么Rust会标记为一个错误。
这里也印证了上面提到的drop
函数的参数类型&mut
,因为发生在清理它的内部元素之前,所以该值在此时必须保留,所以不能是mut self
。也正因为如此,这个值一定是初始化过的(应该是变量初始化过)。
上面Appellation
类型的一个示例Drop
实现代码为:
impl Drop for Appellation {
fn drop(&mut self) {
print!("Dropping {}", self.name);
if !self.nicknames.is_empty() {
print!(" (AKA {})", self.nicknames.join(", "));
}
println!("");
}
}
假定实现为上述代码,那么我们可以接下来写一段测试代码:
{
let mut a = Appellation {
name: "Zeus".to_string(),
nicknames: vec!["cloud collector".to_string(),
"king of the gods".to_string()]
};
println!("before assignment");
a = Appellation { name: "Hera".to_string(), nicknames: vec![]};
println!("at end of block");
}
那么运行得到的结果是什么呢?我们一行一行来分析代码:
before assignment
并换行。owner
了,因此符合清理的条件,Rust会自动对其进行清理,在该值上调用drop
函数drop
函数首先打印值的name
,这里应该是Dropping Zeus
。注意这里是print!
,未换行。nicknames
不为空,将它的元素使用,
连接起来,所以应该为 (AKA cloud collector,king of the gods)
。注意这里是print!
,未换行,因此是接在Dropping Zeus
之后。println!("");
目的是产生换行。at end of block
。drop
函数。drop
函数,打印对象名称,此时应该为Dropping Hera
。Appellation
值的nicknames
字段为空向量,所以不再打印AKA
相关。最终输出结果为:
before assignment
Dropping Zeus (AKA cloud collector, king of the gods)
at end of block
Dropping Hera
上面的代码中,类型为Appellation
的变量a前后有两个不同的值,因此触发了两次清理。第一次清理发生在重新赋值时,此时第一个值被抛弃,变成了无owner
,所以触发清理。第二次发生在代码块结束 ,此时a超出作用域,也触发清理。
可以看到,我们的清理并没有清除掉内部元素占用的资源,这是Rust会在接下来自动处理的,我们的工作主要是作一些额外的处理。
针对这个问题,书中已经给了明确答案。Rust自动清理内部元素,而内部元素也会自动清理自己。例如Vec类型也实现了Drop
特型,它会清理掉它的内部元素并释放它占用的堆上的缓冲区。字符串内部使用Vec
来保存它的文本,因此字符串并不需要自己实现Drop
特型(Vec
实现了就可以),向量本身来处理这些字符的释放。相同的原则应用于Appellation
值,向量的Drop
实现会自动释放它的元素。对于 Appellation
值本身,它也有一个owner
,它可以是本地临时变量或者某些数据结构,这个变量对释放它负责。
注意:
当一个变量的值被移走时,该变量就是未初始化的,因此在超过作用域时并不会触发drop,没有值需要清理。切记,清理的是值不是变量。
下面的一段代码:
let p;
{
let q = Appellation { name: "Cardamine hirsuta".to_string(),
nicknames: vec!["shotweed".to_string(),"bittercress".to_string()] };
if complicated_condition() {
p = q;
}
}
println!("Sproing! What was that?");
根据complicated_condition
返回值的不同,p或者q其中的一个在代码结束时会拥有这个Appellation
值,另一个变量是未初始化。这也决定了他们是在最后的println!
之前还是之后drop
(这是因为q的作用域在println!
之前结束而p的作用域在这之后结束)。虽然在Rust中一个值可以从一个变量移到另一个变量,但是只会清理一次。
通常情况下,你不需要给自己定义的类型实现Drop
特型,除非它拥有了Rust所不能自动处理的资源。例如,在Unix
系统中,Rust标准为使用如下的内部结构来代表操作系统文件描述:
struct FileDesc {
fd: c_int,
}
其中fd
字段代表的文件描述数字在程序结束的时候应该关掉。标准库因此为之实现了Drop
特型来关掉它。
impl Drop for FileDesc {
fn drop(&mut self) {
let _ = unsafe { libc::close(self.fd) };
}
}
这里,libc::close
是C语言库的close
函数的Rust名字,Rust只能在unsafe
代码块中调用C语言的函数。
知识点:
如果一个类型实现了Drop
特型,那么它不能再实现Copy
特型。如果一个类型是Copy
类型,那么意味着简单的字节复制就够了,这样可能会导致两个变量会拥有同一块数据。但是如果两个变量都面临清理时,相同的数据就会清理两次,这是一个错误。就好像上面的FileDesc
例子,如果它实现了Copy
特型,那么另一个变量也会关闭相同的fd
数字,显然这是一个错误。
进一步思考,如果把Copy
换成Clone
呢?经过测试是没有问题的。
use std::ops::Drop;
// A unit struct without resources
#[derive(Debug, Clone)]
struct Unit;
impl Drop for Unit {
fn drop(&mut self) {
println!("in drop");
}
}
fn main() {
let a = Unit;
let b = a.clone();
println!("over:{:?}",b);
}
运行结果为:
over:Unit
in drop
in drop
有人说那如果把FileDesc
设计为实现Clone
特型不一样么?其实还真不一样,因为fd
字段的排它性,所以把它设计为Clone
是错误的。只有可以复制的资源才能设计为实现Clone
特型,这个问题其实是Clone
特型的设计问题了,而不是Drop
特型的问题。
有人说如果两个变量都包含对同一块数据的引用,那么是不是清理两次呢?显然不是,引用不拥有值,不会触发清理。
标准前置还包含了一个drip
函数用来清理一个值,但是它的定义相当魔幻:
fn drop<T>(_x: T) { }
从代码中可以看出,它接收一个值并且获得了该值的owner
。在函数结束时_x
超出了作用域而会被Rust正常的清理掉。这里只是提供了一个便利功能,并不是手动调用值的drop
函数。