• Temporal safety: 简单来说就是use after free
• Spatial safety: 简单来说，就是out of bound访问
• Logic error
• DCHECK: 简单来说，就是debug assert的条件在release版本中被触发了

其他不多展开。

let x = 0;x = 10;  // error
let mut y = 0;y = 10;  //ok

fn foo(x: u32) {}
let x: i32 = 0;foo(x);  // error

class ABC{public:    virtual ~ABC();
    ABC(const ABC&) = delete;    ABC(ABC&&) = delete;
    ABC& operator=(const ABC&) = delete;    ABC& operator=(ABC&&) = delete;};

明明是一件非常常规的东西，写起来却那么的复杂。

fn main(){    // String类似std::string，只支持显式clone，不支持隐式copy    let s: String = "str".to_string();        foo(s);  // s will move    // cannot use s anymore
    let y = "str".to_string();    foo(y.clone());
    // use y is okay here}
fn foo(s: String) {}
// can only be passed by movestruct Abc1{    elems: Vec<int>}
// can use abc.clone() to explicit clone a new Abc#[derive(Clone)]struct Abc2{    elems: Vec<int>}
// implement custom destructor for Abcimpl Drop for Abc2 {    // ...}
// foo(xyz) will copy, 不能再定义Drop/析构函数，因为copy和drop是互斥的#[dervie(Clone, Copy)]struct Xyz{    elems: i32}

let mut x = 10;
foo(x);  // pass by move, x cannot be used after the callfoo(&x);  // pass by immutable referencefoo(&mut x); // pass by mutable reference

• errno
• std::exception
• std::error_code/std::error_condition
• std::expected

看，连标准库自己都这样。std::filesystem，所有接口都有至少两个重载，一个抛异常，一直传std::error_code。

enum MyError{    NotFound,    DataCorrupt,    Forbidden,    Io(std::io::Error)}
impl From<io::Error> for MyError {    fn from(e: io::Error) -> MyError {        MyError::Io(e)    }}
pub type Result<T> = result::Result<T, Error>;
fn main() -> Result<()>{    let x: i32 = foo()?;    let y: i32 = bar(x)?;
    foo();  // result is not handled, compile error
     // use x and y}
fn foo() -> Result<i32>{    if (rand() > 0) {        Ok(1)    } else {        Err(MyError::Forbidden)    }}

错误处理一律通过Result<T, ErrorType>来完成，通过?，一键向上传播错误（如同时支持自动从ErrorType1向ErrorType2转换，前提是你实现了相关trait），没有错误时，自动解包。当忘记处理处理Result时，编译器会报错。

cargo testcargo bench

cargo规定了目录风格

benches  // benchmark代码go heresrctests  // ut go here

let s = vec![1,2,3];  // s owns the Vecfoo(s);  // the ownership is passed to foo, s cannot be used anymore
let x = vec![1,2,3];let a1 = &x[0];let a2 = &x[0];  // a1/a2 are both immutable ref to x
x.resize(10, 0);  // error: x is already borrowed by a1 and a2
println!("{a1} {a2}");

这种unique ownership + borrow check的机制，能够有效的避免pointer/iterator invalidation bug以及aliasing所引发的性能问题。

let s: &String;
{    let x = String::new("abc");    s = &x;}
println!("s is {}", s);  // error, lifetime(s) > lifetime(x)

这个例子比较简单，再看一些复杂的。

// not valid rust, for exposition onlystruct ABC{    x: &String,}
fn foo(x: String){    let z = ABC { x: &x };
    consume_string(x);  // not compile, x is borrowed by z    drop(z);  // call destructor explicitly
    consume_string(x);  // ok
    // won't compile, bind a temp to z.x    let z = ABC { x: &String::new("abc") };    // use z
    // Box::new == make_unique    // won't compile, the box object is destroyed soon    let z = ABC{ x: &*Box::new(String::new("abc") };    // use z}

再看一个更加复杂的，涉及到多线程的。

void foo(ThreadPool* thread_pool){    Latch latch{2};
    thread_pool->spawn([&latch] {        // ...        latch.wait();  // dangle pointer访问    });
    // forget latch.wait();}

这是一个非常典型的lifetime错误，C++可能要到运行时才会发现问题，但是对于Rust，类似代码的编译是不通过的。因为latch是个栈变量，其lifetime非常短，而跨线程传递引用时，这个引用实际上会可能在任意时间被调用，其lifetime是整个进程生命周期，rust中为此lifetime起了一个专门的名字，叫'static。正如cpp core guidelines所说：CP.24: Think of a thread as a global container ，never save a pointer in a global container。

fn foo(thread_pool: &mut ThreadPool){    let latch = Arc::new(Latch::new(2));    let latch_copy = Arc::clone(&latch);
    thread_pool.spawn(move || {        // the ownership of latch_copy is moved in        latch_copy.wait();    });
    latch.wait();}

再看一个具体一些例子，假设你在写一个文件reader，每次返回一行。为了降低开销，我们期望返回的这一行，直接引用parser内部所维护的buffer，从而避免copy。

FileLineReader reader(path);
std::string_view<char> line = reader.NextLine();std::string_view<char> line2 = reader.NextLine();
// opsstd::cout << line;

let reader = FileReader::next(path);let line = reader.next_line();
// won't compile, reader is borrowed to line, cannot mutate it nowlet line2 = reader.next_line();
println!("{line}");

// &[u8] is std::span<byte>fn foo() -> &[u8] {    let reader = FileReader::next(path);    let line = reader.next_line();
    // won't compile, lifetime(line) > lifetime(reader)    return line;}

总结来说，Rust定义了一套规则，按照此规则进行编码，绝对不会有lifetime的问题。当Rust编译器无法推导某个写法的正确性时，它会强制你使用引用计数来解决问题。

let i: i32;
if rand() < 10 {    i = 10;}
println!("i is {}", i);  // do not compile: i is not always initialized

• Send: 一个类型是Send，表明，此类型的对象的所有权，可以跨线程传递。当一个新类型的所有成员都是Send时，这个类型也是Send的。几乎所有内置类型和标准库类型都是Send的，Rc（类似local shared_ptr）除外，因为内部用的是普通int来计数。
• Sync: 一个类型是Sync，表明，此类型允许多个线程共享（Rust中，共享一定意味着不可变引用，即通过其不可变引用进行并发访问）。

Send/Sync是两个标准库的Trait，标准库在定义它们时，为已有类型提供了对应实现或者禁止了对应实现。

• lifetime机制要求：一个对象要跨线程传递时，必须使用Arc（Arc for atomic reference counted）来封装（Rc不行，因为它被特别标注为了!Send，即不可跨线程传递）
• ownership+borrow机制要求：Rc/Arc包装的对象，只允许解引用为不可变引用，而多线程访问一个不可变对象，是天生保证安全的。
• 内部可变性用于解决共享写问题：Rust默认情况下，共享一定意味着不可变，只有独占，才允许变。如果同时需要共享和可变，需要使用额外的机制，Rust官方称之为内部可变性，实际上叫共享可变性可能更容易理解，它是一种提供安全变更共享对象的机制。如果需要多线程去变更同一个共享对象，必须使用额外的同步原语（RefCell/Mutex/RwLock），来获得内部/共享可变性，这些原语会保证只有一个写者。RefCell是与Rc一起使用的，用于单线程环境下的共享访问。RefCell被特别标注为了!Sync，意味着，如果它和Arc一起使用，Arc就不是Send了，从而Arc<RefCell<T>>无法跨线程。

看个例子：假设我实现了一个Counter对象，希望多个线程同时使用。为了解决所有权问题，需要使用Arc<Counter>，来传递此共享对象。但是，以下代码是编译不通过的。

struct Counter{    counter: i32}
fn main(){    let counter = Arc::new(Counter{counter: 0});    let c = Arc::clone(&counter);    thread::spawn(move || {        c.counter += 1;    });
    c.counter += 1;}

因为，Arc会共享一个对象，为了保证borrow机制，访问Arc内部对象时，都只能获得不可变引用（borrow机制规定，要么一个可变引用，要么若干个不可变引用）。Arc的这条规则防止了data race的出现。

fn main(){    let counter = Arc::new(RefCell::new(Counter{counter: 0}));    let c = Arc::clone(&counter);    thread::spawn(move || {        c.get_mut().counter += 1;    });
    c.get_mut().counter += 1;}

为啥？因为RefCell不是Sync，即不允许多线程访问。Arc只在内部类型为Sync时，才为Send。即，Arc<Cell<T>>不是Send，无法跨线程传递。

struct Counter{    counter: i32}
fn main(){    let counter = Arc::new(Mutex::new(Counter{counter: 0}));    let c = Arc::clone(&counter);    thread::spawn(move || {        let mut x = c.lock().unwrap();
        x.counter += 1;    });}

// for demo purpose
fn foo(tasks: Vec<Task>){    let latch = Arc::new(Latch::new(tasks.len() + 1));
    for task in tasks {        let latch = Arc::clone(&latch);        thread_pool.submit(move || {            task.run();            latch.wait();        });    }
    latch.wait();}

这里，latch必须用Arc(即shared_ptr)。

• 函数调用
• 指针别名

C++和Rust都可以通过inline来消除函数调用引起的开销。但是C++面对指针别名时，基本上是无能为力的。C++对于指针别名的优化依赖strict aliasing rule，不过这个rule出了名的恶心，Linus也骂过几次。Linux代码中，会使用-fno-strict-aliasing来禁止这条规则的。

int foo(const int* x, int* y){    *y = *x + 1;
     return *x;}

rust版本

fn foo(x: &i32, y: &mut i32) -> i32{    *y = *x + 1;
    *x}

对应的汇编如下:

# c++__Z3fooPKiPi:    ldr    w8, [x0]    add    w8, w8, #1    str    w8, [x1]    ldr    w0, [x0]    ret
# rust__ZN2rs3foo17h5a23c46033085ca0E:    ldr    w0, [x0]    add    w8, w0, #1    str    w8, [x1]    ret

看出差别没？

• C++的安全性演进是趋势，但是未来很不明朗：C++在全世界有数十亿行的存量代码，期望C++在维持兼容性的基础上，提升内存安全性，这是一个几乎不可能的任务。clang-format与clang-tidy，都提供了line-filter，来对特定的行进行检查，避免出现改动一个老文件，需要把整个文件都重新format或者修改掉所有lint失败的情况。大概也是基于此，Bjarne才会一直尝试通过静态分析+局部检查来提升C++的内存安全性。
• Rust有利于大团队协作：Rust代码只要能编译通过，并且没有使用unsafe特性，那么是能够保证绝对不会有内存安全性或者线程安全性问题的。这大大降低了编写复杂代码的心智负担。然而，Rust的安全性是以牺牲语言表达力而获得的，这对于团队合作与代码可读性，可能是一件好事。至于其他，在没有足够的Rust实践经验前，我也无法作出更进一步的判断。

Relax and enjoy coding！

参考资料：

1、Cpp core guidelines: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

2、Chrome在安全方面的探索：https://docs.google.com/document/d/e/2PACX-1vRZr-HJcYmf2Y76DhewaiJOhRNpjGHCxliAQTBhFxzv1QTae9o8mhBmDl32CRIuaWZLt5kVeH9e9jXv/pub

3、NSA对C++的批评：https://www.theregister.com/2022/11/11/nsa_urges_orgs_to_use/

4、C++ Lifetime Profile: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#SS-lifetime

5、C++ Safety Profile: https://open-std.org/JTC1/SC22/WG21/docs/papers/2023/p2816r0.pdf?file=p2816r0.pdf

6、Herb CppCon2022 Slide: https://github.com/CppCon/CppCon2022/blob/main/Presentations/CppCon-2022-Sutter.pdf

7、Rust所有权模型理解：https://limpet.net/mbrubeck/2019/02/07/rust-a-unique-perspective.html