c语言中文官网零基础c++从入门到精通C语言程序设计门户网站

导语 |云加社区祝大家新年快乐！新春假期结束的第一篇干货，为大家带来的是从C++转向Rust主题的内容。在日常的开发过程中，长期使用C++，在使用Rust的过程中可能会碰到一些问题。本文是From C++ To Rust的第二篇，在这一篇里，主要介绍错误处理和生命周期两个主题。

此前，我介绍了其中思维方式的转变（mind shift）：《详细解答！从C++转向Rust需要注意哪些问题？》

一、错误处理

（一）C++

任何生产级别的软件开发中，错误处理都需要被妥善考虑。C++通常会有两种错误处理的风格：

• 从C继承下来的返回值风格。所有函数都返回整型，用错误码来表示各种错误情况。

• C++的异常，在出错的位置抛出异常，然后在错误处理的位置捕捉异常。

这两种方案各有优劣，这里简单地说明一下。

返回值风格的优点是清晰，错误发生的位置和处理方法都写得很直白；缺点即是拖沓，错误代码与业务代码交错在一起，使得主要逻辑不突出。同时占用了返回值位置，影响逻辑的表达。另外，没有强制错误检查，可能会遗漏错误检查而导致代码缺陷。如下：

if (OK != foo) { // error handle}
SomeThing thing;if (OK != getSomeThing(&thing)) { // error handle}
thing.init; // 可能已经失败了thing.action; // 由于前面忘记检查是否成功初始化，这里可能会故障

异常恰恰相反，错误有独立的处理流，通常不与业务逻辑相交，使得业务逻辑看起 来很清晰；但是由于异常的隐性，使得任何位置都可能抛出异常，函数的退出点也变得隐晦，带来异常安全问题，增加了代码编写的心智负担。如下：

void foo { auto thing = new Thing; bar; // 可能会抛出异常 delete thing;}

如果上面代码中的bar抛出异常，程序的执行流程将从bar函数跳出进入异常处理流程，因此后面delete语句不能得到执行，导致thing泄漏。

解决此问题的方法是使用智能指针，它们使用了RAII机制确保了函数在各种情况下均能妥善地释放动态分配的对象。

（二）Rust

• Result<T，E>

Rust没有提供异常机制，与使用Option来解决可选的情况类似，它使用了Result来提供此功能。Result的定义如下：

pub enum Result<T, E> { /// Contains the success value Ok(T), /// Contains the error value Err(E),}

可以看到，Result的定义几乎与Option一样。只是在异常的情况返回时多带一个错误类型。举一个具体的例子：

#[derive(Debug)]pub enum MyError { IoError(String), Inexist(String),}
pub type Result<T> = std::result::Result<T, MyError>;
pub fn fetch_id -> Result<u64> { Ok(0)}
fn main -> Result<> { let id = fetch_id?; println!("{:?}", id); Ok()}

上面let id=fetch_id?；一句，使用了?操作符，实际相当于执行如下语句：

let id = match fetch_id { Ok(id) => id, Err(err) => { return Err(err); }};

相当于，如果被调函数(fetch_id)正常返回则unwrap其值；反之，则将被调函数的错误向上返回。

相对于C/C++，Rust在此处，实际上在尝试做到某种平衡：

• 没有异常，没有引入新的执行模型。函数的执行流程可以采用简单的返回值方式分析，便于理解。

• ?操作符的引入，使用语法糖一方面减少错误处理代码，代码更清爽；另一方面也显式地注明了所有返回点。

• Result中携带的返回值T必须unwrap之后才能使用，这在类型系统上保证了错误必须被处理，不能沉默地忽略。

• 错误处理是强类型的。通过Result中的E类型参数向上返回错误时，必须要求E类型不变。这里产生了一些Rust错误处理的独特要求，后面再展开。

• 由于Safe Rust不能直接操作裸指针，所以不论函数从什么位置返回，均确保通过RAII机制释放了指针。

  
  

• panic!

在Rust中，错误被划成了两类：可恢复的(recoverable)和不可恢复的(unrecoverable)。所谓可恢复通常指的是可以上报给用户，修复之后，然后重试一下的错误，比如：文件未找到，配置错误等。而不可恢复一般是由于代码Bug导致的，程序已经进入未定义状态，继续执行可能产生未定义行为，比如：数组越界访问。

对于可恢复的错误，使用Result<T，E>返回错误，交由调用方决定该如何处理。而对于不可恢复的错误，使用panic!宏直接中止程序的执行。

（三）Rust错误处理惯例

如之前所说，Rust的错误处理是强类型的。因此，不能像C++的异常一样，错误可以穿透多层调用栈；相反，错误必须被逐层处理、翻译，不能一抛到底。这个工作其实是较为繁琐的。举个例子：

#[derive(Debug)]pub enum MyError { IoError(String), Inexist(String),}
pub type Result<T> = std::result::Result<T, MyError>;
pub fn fetch_id -> Result<u64> { let content = std::fs::read_to_string("/tmp/tmp_id")?; let id = content.parse::<u64>?; Ok(id)}

这段代码不能编译通过，因为std::fs::read_to_string和String::parse的 返回值虽然都叫Result，但却不是相同的类型(因为E被定义为库局部的错误了)。因此，这里都不能直接使用?操作符。而是需要进行错误类型的翻译，转成我们自己定义的MyError：

pub fn fetch_id -> Result<u64> { // 写法1： let content = match std::fs::read_to_string("/tmp/tmp_id") { Ok(content) => content, Err(_) => { return Err(MyError::IoError("read /tmp/tmp_id failed.".to_owned)); } }; // 写法2：使用标准库函数 map_err let id = content .parse::<u64> .map_err(|_| MyError::ParseError("parse error.".to_owned))?; Ok(id)}

显然，写法1过入繁冗，实在称不上优雅。而写法2直接使用标准库函数map_err来完成错误类型的映射，会干净很多。但是如果映射的代码比较复杂，或者同样的处理会多次重复，就会希望将错误映射集的代码中起来。因此，社区中也提供了库来简化这部分处理，如：thiserror，anyhow。这两个库分别对应了库级别与应用级别的错误处理。

所谓库级别指的是编写为可被其它库或者应用复用的代码。因此，并不清楚错误最终会被如何处理，所以最终会在库级别统一Error的类型，并最终将底层转译到该错误类型。如上例中的MyError。上例在使用thiserror改写之后：

#[derive(thiserror::Error, Debug)]pub enum MyError { #[error("io error.")] IoError(#[from] std::io::Error), #[error("parse error.")] ParseError(#[from] std::num::ParseIntError),}
pub type Result<T> = std::result::Result<T, MyError>;
pub fn fetch_id -> Result<u64> { let content = std::fs::read_to_string("/tmp/tmp_id")?; let id = content.parse::<u64>?; Ok(id)}

可以看使用thiserror后，代码清爽了很多。thiserror会为MyError自动实现底层Error的From trait。所以在fetch_id中就可以直接用?操作符将底层 Error映射到MyError。

而应用级别的Error不需要进一步上传给调用者，只需要有一个Result类型 可以集中处理所有的底层Error即可。因此，此时不需要自定义MyError， 使用anyhow改写之后如下：

use anyhow::{Context, Result};
pub fn fetch_id -> Result<u64> { let content = std::fs::read_to_string("/tmp/tmp_id") .context("open /tmp/tmp_id failed.")?; let id = content.parse::<u64>.context("parse error.")?; Ok(id)}
fn main -> Result<> { let id = fetch_id?; println!("{:?}", id); Ok()}

anyhow为泛型(generic)的Result<T，E>实现了Context trait。而Context提供了context函数，将原来的Result<T，E>转成了Result<T，anyhow::Error>，最终在应用级别将错误类型统一到anyhow::Error上。

限于篇幅，这里不再对这两个库做更深入说明，更细致的说明可以参考以下详细文档：

• Rust:Structuring and handling errors in 2020（https://nick.groenen.me/posts/rust-error-handling/）

• thiserror（https://docs.rs/thiserror）

• anyhow（https://docs.rs/anyhow）

二、生命周期

终于到这个主题了！显然生命周期是Rust最独特的特性，没有之一。虽然在各种语言都会定义对象的生命周期，但将其在语言中静态表达出来的只有Rust。因此，虽然早有接触，但是在Rust碰到还是会觉得陌生，甚至晦涩。在这里笔者尝试记录下自己学习这个概念的关键点，想到什么说什么，不会是一个系统的教程，只是记录C++的熟悉者容易忽略的一些点。

（一）谈谈生命周期

简单地说，生命周期就是一个对象的存续时间。对于支持引用的语言来说， 引用目标在使用时必须存在是程序正确运行的基础；同时因为计算机内有限的资源，所以在对象使用完毕后，必须尽早释放。生命周期可以手动管理，但是因为程序的复杂性，手动管理是一件成本很高并且易错的工作。所以也就诞生了各种自动管理生命周期的算法，当前典型的算法有两类，引用计数(RC)和垃圾收集(GC)。

而Rust实际是探索了第三种自动管理的方案：编译期的静态检查-BorrowChecker，它通过分析变量的定义域(Scope)与移动(Move)规则，来保证通过引用使用目标对象的安全性。(注：在NLL BorrowChecker引入后，定义域不再是严格的代码块)。

初次接触Rust，最奇怪的就是生命周期的记法了："a。很陌生，很费解。为什么需要它？解决什么问题？说一下我的理解：

• "a 是一种标记，BorrowChecker通过比较生命周期来保证引用的安全性；

• 一般地，所有引用都含有生命周期标记。只是因为避免语言过于繁冗，Rust允许开发在一些情况下省略该标记(Lifetime Elision)；

• 因为BorrowChecker工作在编译期，所以生命周期标记合并在泛型系统中，具体实现为泛型参数中的一项。

  
  

（二）生命周期省略-Lifetime Elision

Rust为了代码的清爽，允许开发在很多情况下都可以不使用生命周期标记。

这使得生命周期标记的出现场景比较微妙，比如：

fn print(s: &str);

实际上应该理解为：

fn print<"a>(s: &"a str);

该函数接受一个字符串的引用，显然，这个引用目标的生命周期一定可以覆盖 print的执行期，print并不需要对引用的生命周期做更特别的静态检查。因此，Rust允许省略这个生命周期标记。

具体的省略规则可以参考文档：Lifetime Elision

（https://doc.rust-lang.org/nomicon/lifetime-elision.html）

说一下我的理解：

首先定义了输入引用和输出引用，文档中为了严谨，描述得比较长。简单地说，除了函数返回的引用外，其它都是输入引用。然后依据以下规则省略引用：

• 规则1：每个输入引用都给予独立的生命周期；

• 规则2：如果只有一个输入引用，那么该引用的生命周期给到全部省略的输出引用；

• 规则3：如果是多个输入引用，并且其中有&self或者&mut self，那么self的生命周期给到全部省略的输出引用；

• 其它情况都是错误的，必须显式地进行生命周期标注。

虽然Rust允许开发省略标注，但是需要注意的是：Rust根据上面规则自动恢复的标注，有可能并不是你想要表达的目的。如文档中的例子：

fn substr(s: &str, until: usize) -> &str;

应用规则2，取消省略之后：

fn substr<"a>(s: &"a str, until: usize) -> &"a str;

在取子串的情形中，返回的子串生命周期与输入参数一致，因此，默认恢复的标注是合理的。但是如果是下面函数：

fn country_abbr(c: &str) -> &str { match c { "China" => "CN", "America" => "US", _ => "Unknown", }}

应用规则2，取消省略后的签名是：

fn country_abbr<"a>(c: &"a str) -> &"a str;

可以知道，返回的“CN”，“US”，“Unknown”的生命周期是"static，由于"static的长度比所有其它生命周期都长，因此，将其以&"a str的类型返回不会有编译错误。但是这个结果会缩小country_abbr的使用范围，这可能并不是我们想要的结果。如下代码会无法编译通过：

fn check_lifetime(abbr: &"static str) {}
check_lifetime(country_abbr("China"));

所以，在了解了生命周期的省略规则后，country_abbr的签名应该写作：

fn country_abbr(c: &str) -> &"static str;

另一个需要注意的地方是：对于接受多个引用参数的函数，每个引用的生命周期都是独立的。如下：

fn foo(bar: &str, baz: &str);

应该应用规则1和规则2展开为：

fn foo<"a, "b>(bar: &"a str, baz: &"b str);

而不是:

fn foo<"a>(bar: &"a str, baz: &"a str);

因为后期实际上要求了两个参数的生命周期必须是一样的， 因此施加了比前者更强的约束。

（三）子类化(Subtyping)与变型(Variance)

写下这个标题时，我心里也是没有什么底的：因为相对来说这是一些抽象及陌生的概念，使用简单且易于理解的语言将其说明白，对我来说是也很大的挑战。下面的说明都是使用自己理解的语言来表达的，不追求特别严谨精确，但希望易于理解。

• 子类化Subtyping

为了加快思考，人脑会将一些常用的推导变成直觉，不自觉地忽略底层的逻辑细节，子类化(Subtyping)就是其中一个例子。因为在C++中，子类关系通常在继承关系中体现，所以从C++转过来的话，很容易下意识地认为子类就是继承。而事实上，子类关系是比继承关系更一般的(generic)关系。或者换句话说，继承关系是子类关系的一种实现。

所以，在Rust中不能简单地将子类化理解为继承，需要重新整理一下。笔者从几个点来理解：

• 子类关系符合里氏替换原则。即是说，如果S是T的子类，那么类型为T的形参可以填入类型为S的实参。说人话：在需要使用某个类型的场合，也可以使用该类型的子类来代替。白话：子类比超类更有用。

• 在逻辑学中，内涵指概念所拥有的属性；而外延指的具备概念属性的事物。对应到类型系统，内涵指是某个类型的属性或方法；而外延指的是该类型的所有实例。所以，子类比超类有更多内涵，更少外延；而超类反之。

说了这么多，终于可以回到生命周期主题了。笔者在学习生命周期的过程中， 碰到第一个反直觉的结论是："static是所有其它生命周期的子类，可以写作"static<: "a ("a是任意任命周期)。你看：明明"static是最长最大最多的生命周期，为什么是子类？是小的那端？理解起来很不自然。

后来一句话解了我的疑惑：生命周期的长度体现的是内涵。这句话想想还有点哲学意味。

因此，<: 描述的是外延的大小，所以，任何大于"a的生命周期都是"a的实例，而"static的实例只有一个，就是"static本身。显然，"a的外延大于"static，所以"static是子类。从有用性的角度理解，"static可以在任何需要生命周期的地方使用，是最有用的，所以根据前面说到的，子类比超类更有用，"static显然是子类。

• 变型Variance

在介绍变型之前，需要先引入另外一个概念类型构造子(Type Constructor)。首先这个概念要与C++中的构造函数(Constructor)区别开来：构造函数是用于创建类型的新实例；而类型构造子则是用于创建新类型：

• 可以是和类型或者积类型的构造。在Rust中可以认为是enum或者struct的定义式；

• 可以是泛型类型的实例化。如：Vec<u8>。

在考虑变型时，主要是第二种情形，即：泛型类型的实例化。我们可以将泛型类型理解为类型的函数，因为其接收类型参数，返回新的类型。这样，我们就可以引出变型的三种情况了：

假设有类型构造子：F<T>, 并且有两个具体的类型：Super和Sub满足Sub<:Super，这两个具体类型通过F<T>可以分别构建新类型F<Sub>和F<Super>

• 协变-covariance: 如果新类型和类型参数的关系一致，即满足 F<Sub> <: F<Super>，则称之为F<T>对T协变。

• 逆变-contravariance: 如果新类型和类型参数的关系相反，即满足 F<Super> <: F<Sub>，则称之为F<T>对T逆变。

• 不变-invariance: 如果新类型和类型参数的关系无关，即不满足任何约束，则称之为F<T>对T不变。

终于介绍完了两个抽象概念，可以回来谈Rust了。

Rust当前没有定义类型间的子类关系。trait虽然可以继承，但并不是符合定义的子类关系（无法将&dyn Derive直接传给&dyn Base）。因此，在当前版本的Rust中，子类关系只在生命周期中存在。

在Rust的文档中，有一个表描述了各种类型的变型关系，这里针对不太容易理解的两种情况进一步说明：

• &"a mut T为什么对T是不变(invariant)?

根据《锈灵书》在介绍变型的相关章节中提供的例子：

fn evil_feeder(pet: &mut Animal) { let spike: Dog = ...;
 // `pet` is an Animal, and Dog is a subtype of Animal, // so this should be fine, right..? *pet = spike;}
fn main { let mut mr_snuggles: Cat = ...; evil_feeder(&mut mr_snuggles); // Replaces mr_snuggles with a Dog mr_snuggles.meow; // OH NO, MEOWING DOG!}

&mut T对T的不变性(invariant) 是为了阻止通过修改超类的引用&mut Animal将Dog的实例复制到Cat的内存上(*pet=spike)。但是这个例子还是有一些不清晰的地方：

如前面所述，类型间的子类关系在Rust并未定义，所以这里上面提到“Dog is a subtype of Animal”并不准确。

另外，由于trait object是一个动态尺寸类型(dynamic sized type)，所以必须Dog，Cat必须位于某种指针之后，因此，let spike: Dog=...不是合法的代码。

从逻辑上说，拿到某个类的指针，并不能用子类(当然也不能用超类)实例去覆盖该类的实例，因此，&mut T应该是不变的(invariant)。笔者推测是否也是Rust为了保留以后类型子类化的能力。

• fn(T)-> 为什么对T是逆变(contravariant)?

这是文档中唯一的逆变的例子，所以多说明一下。fn(T) -> 是函数类型，用该类型描述某个作用场景(即，参数位置)时，其实是回调的场景。因此，回调函数的参数类型T，实际是对调用方的要求。这个要求越少(即，更加泛化，约束少，更偏向超类)， 回调函数反而使用场景更大(即，更有用)。前面已经说到，更有用的是子类。

举个例子：

struct A;
fn foo(cb: fn(a: &A)) { let a = A; cb(&a);}
fn cb0(_a: &A) { println!("cb0 called.");}
fn cb1(_a: &"static A) { println!("cb1 called.");}
fn main { foo(cb1);}

这里cb1的参数类型&"statc A是cb0的参数类型&"a A的子类，但是cb1却不能被foo接受。

（四）关于生命周期容易产生的误解

在Rust中，生命周期是全新的概念，因此也容易理解错误，对于常见的情形，Common Rust Lifetime Misconceptions一文介绍得非常清楚。

文档：（
https://github.com/pretzelhammer/rust-blog/blob/master/posts/common-rust-lifetime-misconceptions.md#
3-a-t-and-t-a-are-the-same-thing）

如果刚开始学习Rust特别需要注意：

• T既是&T也是&mut T的超类；

• &T和&mut T是不相交的集合。

对于熟悉C++重载规则的开发来说，这两点是需要注意的。在Rust中，因为T包含&T，所以，不能同时为T，&T实现一个trait. 如下：

trait Trait {}
impl<T> Trait for T {}
impl<T> Trait for &T {} // ❌

&mut T和T也同理。因此，要为引用实现trait应该写作：

trait Trait {}
impl<T> Trait for &T {} // ✅
impl<T> Trait for &mut T {} // ✅

另外，即是要区分好，T: "static和&"static T，主要规则如下：

• T: "static 应该读做：类型T被生命周期"static定界；

• 如果T: "static, 那么，T可以是生命周期为"static的借用类型，或者是拥有所有权的类型。

因为T: "static包括拥有所有权类型，所以T：

• 可以在运行时动态分配；

• 不必在程序运行的整个生命周期有效；

• 可以安全地被修改；

• 可以在运行时动态释放；

• 可以具备不同的存续期。

更加一般地，T: "a和&"a T的规则如下：

• T: "a比 &"a T更具弹性且通用；

• T: "a可以接受拥有所有权的类型，包含引用的拥有所有权类型或者引用；

• &"a T只接受引用；

• 如果T: "static那么T: "a因为对于所有"a有"static >="a。

  
  

三、后记

这两个主题比我想像花了更多的篇幅，所以这一篇先到这里吧。后面计划继续聊聊可修改性Mutablility和异步Async。

作者简介

孟杰

腾讯后台开发工程师

本文由高可用架构翻译。技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。

高可用架构

改变互联网的构建方式