CMSC330

Slices reference a part of a continuous piece of memeory

let x = String::from ("Hello World");
let hello = &x[0..5];
let world = &x[6..11];
x: String
  ptr -> Hello World
  len: 11
  capacity: 11
hello: &str
  ptr -> x.ptr
  len: 5
world: &str
  ptr -> x.ptr[6]
  len: 5

If x is dropped, so is everything else

x cannot be modifed while slices exist

Slices reference a part of a continuous piece of memeory

let a = [1,2,3,4];
let v = Vec::new();;
v.push(1);
let b = &a[1..3]
let w = &v[..2]

Arrays and vectors also have slices

Slices reference a part of a continuous piece of memeory

Arrays and vectors also have slices

This is because we need to talk about parts of already existing data

This is because we need to talk about parts of already existing data

fn first_word(x:&String) -> &String{
  x[0..x.find(" ").unwrap()] //error
}

A String is something from String::from(...)

Above does not return a string, but a substring

Enter "substring type": &str

Enter "substring type": &str

Slices reference a part of a continuous piece of memeory

There are String Slices, Array Slices, Vector Slices, etc

There are String Slices, Array Slices, Vector Slices, etc

Common to use a slice instead of the data structure itself

Subtyping: all Strings are string slices

struct User {
    username: String,
    active: bool,
}
let user1 = User {
  username: String::from("clyff"),
  active: true,
}
println!("{}",user1.username);

Structs have associated functions

struct User {
    username: String,
    active: bool,
}
 
impl User{
  fn is_online(&self){
    self.active
  }
}

Enums also are helpful for custom data types

enum Color{
  Green,
  Red,
  Blue,
  Other(String)
}
 
let r = Color::Red;
let o = Color::Other(String::from("Grey"));

Enums also have associated functions

impl Color{
  fn is_green(&self)->bool{
    match self{
      Color::green => true,
      _ => false,
    }
  }
}

Both Enums and Structs allow for Generics

struct Point<T>{
  x:T,
  y:T,
}
 
enum option<T>{
  None,
  Some(T),
}

Same for associated Functions

impl<T > Point<T>{
  fn x(&self) -> &T{
    &self.x
  }
}

Hashmaps are built into Rust

let x = HashMap<i32,String>::new();

Can have multiple and on a generic

struct Point<T:Clone + PartialOrd>{
  x:T,
  y:T,
}

Common Traits

• Copy
• Clone
• Move
• Deref
• Display

Lifetimes are an implicit generic

They are elided (ommited)

fn longest(x: &str, y: &str) -> &str {
  if x.len() > y.len() {
    x
  } else {
    y
  }
}

Rust Compiler makes deductions about lifetimes

Sometime's it doesn't have enough data

Programmer has to step in and stop eliding

Programmer has to step in and stop eliding

fn longest(x: &str, y: &str) -> &str {
  if x.len() > y.len() {
    x
  } else {
    y
  }
}

Return type has no gaurantee it's a valid reference

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
  if x.len() > y.len() {
    x
  } else {
    y
  }
}

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
  if x.len() > y.len() {
    x
  } else {
    y
  }
}

Return type has no gaurantee it's a valid reference

Why? Rules of lifetime elision

Rules of lifetime elision (of functions)

• Every input reference gets a unique lifetime
• If one input lifetime, output matches that lifetime
• If one param is &(mut)self, output matches that lifetime

• Every input reference gets a unique lifetime

fn somefunc(x:&str, y: &str) -> usize {
...
}

gets elided to

fn somefunc<'a, 'b>(x:&'a str, y: &'b str) -> usize {
...
}

• Every input reference gets a unique lifetime

fn somefunc(x:&str, y:i32, z:&str) -> usize {
...
}

gets elided to

fn somefunc<'a, 'b>(x:&'a str, y:i32, z:&'b str) -> usize {
...
}

If one input lifetime, output matches that lifetime

fn somefunc(x:&str) -> &str{
...
}

gets elided to

fn somefunc<'a>(x:&'a str) -> &'a str{
...
}

If one input lifetime, output matches that lifetime

fn somefunc(x:&str, y:i32) -> &str{
...
}

gets elided to

fn somefunc<'a>(x:&'a str, y:i32) -> &'a str{
...
}

If one param is &(mut)self, output matches that lifetime

fn somefunc(&self, x:&str) -> &str{
...
}

gets elided to

fn somefunc<'a,'b>(&'a self, x:&'b str) -> &'a str{
...
}

x is 'b due to rule one

Structs with references need explicit lifetimes as well

struct ImportantString<'a>{
  istring: &'a str,
}

The instance of ImportantString cannot outlive the reference it holds

let x = String::from("Hello world");
{
  let y = ImportantString {istring:&x };
}

We can do anonymous functions

Ownership and borrowing still apply

let s = String::from("hello");
let f = |x| println!("{x}");
f(s);
println!("{s}") // error

let s = String::from("hello");
let f = || println!("{s}");
f();
println!("{s}") // ok!

let mut s = String::from("hello");
let mut f = || s.push_str(" world");
f();
println!("{s}");

function traits are applied based off behavior

References are pointers

let x = 5;
let y = &x;
 
assert_eq!(5, x);
assert_eq!(5, *y);
assert_eq!(5, y); //error here

Boxes are pointers

let x = 5;
let y = Box::new(&x);
 
assert_eq!(5, x);
assert_eq!(5, **y);

Box has Deref and Drop traits

We can use this for functions

fn f(x: &str){
  println!("echoing {x}")
}
 
let a = Box::new(String::from("echo..."));
f(&a);

Use DerefMut for mutability

(Cannot go from immut to mut)

Sometimes Box is not sufficient

let a = Node(3, Box::new(Box::new(Nil)),Box::new(Nil));
let b = Node(2, Box::new(Box::new(Nil)),Box::new(Nil));
let c = Node(1, Box::new(a),Box::new(b));
let d = Node(4, Box::new(a),Box::new(a)); //not ok

We can fix with RC (Reference counting)

We can fix with RC (Reference counting)

Allows for multiple owners with trade off of potential memory leaks

enum Tree{
  Node(i32,Rc<Tree>,Rc<Tree>),
  Nil
}
let a = Rc::new(Node(3, Rc::new(Nil),Rc::new(Nil)));
let b = Rc::new(Node(2, Rc::new(Nil),Rc::new(Nil)));
let c = Node(1, Rc::clone(&a),Rc::clone(&b));
let d = Node(4, Rc::clone(&a),Rc::clone(&a)); 

Has all tradeoffs of RC

(like cyclic structures)