Administrivia

• “Lab 3: FAT32 Filesystem” is out and due in 3 week (DUE: Mar 2)!
  • 1.8K lines, 11.1K words, 73.0K characters

Administrivia

• Final project
  • Proposal Day is on Feb 27th (slides due on 26th)
  • About 2-4 people per team
  • Due: upload the proposal slides the day before the proposal day
  • Check our web site for ideas

Q&A

• Trick question: Box is considered (still) primitive (see, later)!

impl<T: ?Sized> Deref for Box<T> {
    type Target = T;

    fn deref(&self) -> &T {
        &**self // Q?
    }
}

Ref. “Rust Tidbits: Box Is Special”

Q&A

Can you please go over the difference between " impl thing for &StackVec " and “impl thing for StackVec”?

What is the most important contribution that rust has given the academic community? What companies hire for rust and for what kind of systems?

Ref. Why Discord is switching from Go to Rust

About Discord’s story

• “Read States” service, written in Go (i.e., GC on LRU cache)

About Discord’s story

• Go vs. Rust version (unoptimized)

About Discord’s story

• Go vs. Rust version (w/ larger LRU, note on the scale of Max)

Agenda

• Smart pointers overview
• Implementing Box<T>

Smart Pointers in C++

• Q. What’s a pointer in C/C++?
• Q. What problems does a smart pointer aim to solve?

// overriding pointer semantics
T & operator * () { ... }
T * operator -> () { ... } 

std::unique_ptr<T>; // in charge of deallocation
std::shared_ptr<T>; // RC-based ownership (never freed when holding a ptr)
std::weak_ptr<T>;   // weak ownership (can be freed while holding a ptr)

Smart Pointers in Rust

• Q. What do you mean by pointer in Rust? (vs., raw pointer?)
• Q. What’s a reference?

Smart Pointers in Rust

• Loosely defined! perhaps, proxy/wrapper would be better terms
• “Smart pointers” behave as if it owns (or points to) the underlying data

let s = String::from("Hello");
*s; // <- Q. what does it mean by?

let b = Box::new("Hello");
*b; // <- Q. what does it mean by?

let r = Rc::new("Hello");
*r; // <- Q. what does it mean by?

Smart Pointers in Rust

• To mimic the behavior of a pointer, two operations should be overridden:
  1. Dereferencing: *ptr (i.e., Deref/DerefMut)
  2. Destruction: ptr goes out of scope (i.e., Drop)

Deref

• Used for dereferencing operations, like *v
  • Deref for immutable dereferencing
  • DerefMut
• Deref/DerefMut to assist smart pointers
• Should be never failed

Deref coercion

• A smart pointer can behave like what it points to:

v = *x;     // v = *Deref::deref(&x)
*x = v;     // *DerefMut::deref_mut(&mut x) = v

x.func();   // x -> Deref::deref(&x) if func() exists
func(&x);   // &x -> Deref::deref(&x) if func accepts

Example: String

// @liballoc/string.rs
impl ops::Deref for String {
    type Target = str;

    fn deref(&self) -> &str { .. }
}

let s = String::from("hello");

// str::to_uppercase() -> String
s.to_uppercase(); // String -> &str via deref()

Rc: reference counted pointer

• Rc<T> enables shared ownership of data

let r1 = Rc::new(String::from("hello"));
println!("{}", r1);

// both r1/r2 points (i.e., behaves as if it owns) to String
let r2 = Rc::clone(&r1);
println!("{}", r1);
println!("{}", r2);

Example: Rc

let gadget_owner: Rc<Owner> = Rc::new( // rc++
  Owner {
    name: "Gadget Man".to_string(),
  }
);

let gadget1 = Gadget {
  id: 1,
  owner: Rc::clone(&gadget_owner),     // rc++
};
let gadget2 = Gadget {
  id: 2,
  owner: Rc::clone(&gadget_owner),     // rc++
};

drop(gadget_owner);                    // rc--, but no free!

vs. Reference

• Q. How to compare Rc with & (or &mut)?

vs. Reference

• Q. How to compare Rc with & (or &mut)?
  1. Tracking lifetime/ownership at runtime vs., compile
  2. Storage cost, shareable with other threads (note, Arc)

vs. Reference

• Q. When would be useful to use Rc?

vs. Reference

• Q. When would be useful to use Rc?
  1. Recursive data structure to avoid redundant stores
  2. Too difficult to reason about lifetime at compile time

vs. Reference

• Q. Is it safe?

vs. Reference

• Q. Is it safe?
  1. Yes, just like shared references!
  2. Yet, no way we can implement Rc by using only safe Rust? (later!)

Example: rc

// Q1. ?Sized?
pub struct Rc<T: ?Sized> {
    ptr: NonNull<RcBox<T>>,
    phantom: PhantomData<T>, // Q2. PhantomData?
}

PhantomData

• Acts like it owns T
  1. Unused lifetime parameters
  2. Unused type parameters
  3. Ownership and the drop check

Ref. Nomicon: 3.10. PhantomData

Example: PhantomData (unused lifetime param)

struct Slice<'a, T> {
  start: *const T,
  end: *const T,
}

struct Slice<'a, T: 'a> {
  start: *const T,
  end: *const T,
  phantom: PhantomData<&'a T>,
}

Example: rc::new()

pub fn new(value: T) -> Rc<T> {
  Rc {
    ptr: Box::into_raw_non_null(box RcBox {
                strong: Cell::new(1),
                weak: Cell::new(1),
                value,
    }),
    phantom: PhantomData,
  }
}

Let’s implement Box

• Using libc’s malloc/free (unsafe)
• Implementing Drop
• Implementing Deref/DerefMut

One difference: Move a value out of a box

• No way we can implement this syntax, even w/ unsafe code

let x = Box::new(vec![1,2,3,4]);
let y = *x; // moves the vec out into `y`, then deallocates the box
            // but does not call a destructor on the vec

Ref. “Rust Tidbits: Box Is Special”

References

• Book:Ch15
• Rust by Example: Conversion
• Cheat sheet