作者最近尝试写了一些Rust代码,本文主要讲述了对Rust的看法和Rust与C++的一些区别。
背景
C++代码中的风险
-
Temporal safety: 简单来说就是use after free -
Spatial safety: 简单来说,就是out of bound访问 -
Logic error -
DCHECK: 简单来说,就是debug assert的条件在release版本中被触发了
其他不多展开。
Rust初体验
默认不可变
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 move
struct 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 Abc
impl 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 call
foo(&x); // pass by immutable reference
foo(&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时,编译器会报错。
内置格式化与lint
标准化的开发流程和包管理
cargo test
cargo bench
cargo规定了目录风格
benches // benchmark代码go here
src
tests // ut go here
Rust在安全性的改进
lifetime安全性
let s = vec![1,2,3]; // s owns the Vec
foo(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 only
struct 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();
// ops
std::cout << line;
let reader = FileReader::next(path);
let line = reader.next_line();
// won't compile, reader is borrowed to line, cannot mutate it now
let 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
Rust的多线程安全性
-
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;
});
}
Rust的性能
// 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
标签:初体验,C++,Arc,let,lifetime,foo,Rust From: https://www.cnblogs.com/88223100/p/A-CPP-programmers-initial-experience-with-Rust.html