Add notes for Rust, C & C++, Graph Theory, DSP

Author: rkshthrmsh

Advanced Features.md

@@ -0,0 +1,66 @@
+# Advanced Features
+#rust 
+
+## [[Unsafe Rust]]
+
+## [[Advanced Traits]]
+
+## Advanced Types
+### Using the Newtype Pattern for Type Safety and Abstraction
+- The [[Advanced Traits#Implementing External Traits on External Types|newtype]] pattern is a lightweight way to achieve [[OOP Features of Rust#Characteristics of Object-Oriented Languages#Encapsulation|encapsulation]].
+
+### Creating Type Synonyms with Type Aliases
+- Rust provides the ability to declare a _type alias_ to give an existing type another name. For this we use the `type` keyword.
+```rust
+type Kilometers = i32;
+let x: i32 = 5;
+let y: Kilometers = 5;
+println!("{}", x + y);
+```
+- This method merely renames the type and provides no type checking benefits that we got from the [[Advanced Traits#Implementing External Traits on External Types|newtype]] pattern.
+- The main sue case is to reduce repetition. For this reason they are also commonly used with the `Result<T, E>` type. For this reason, `std::io` has a type alias declaration:
+```rust
+type Result<T> = std::result::Result<T, std::io::Error>;
+```
+
+### The Never Type that Never Returns
+- Rust has a special type named `!` that’s known in type theory lingo as the _empty type_ because it has no values. 
+- Rust prefers to call it the _never type_ because it stands in the place of the return type when a function will never return.
+```rust
+fn bar() -> ! {
+	// body
+}
+```
+- Functions that never return are called _diverging functions_. `bar` above is an example.
+- The never type is useful in situations where a function has to deal with `panic!` or `continue` statements. The Rust compiler does not permit a function to have different return types. For example, a function cannot return both an integer and a string based on a conditional statement. However, a situation like this is exactly what occurs in the following common-place code.
+```rust
+let guess: u32 = match guess.trim().parse() {
+	Ok(num) => num,
+	Err(_) => continue, // return type of continue is not same as num.
+}
+```
+- In the above example, `continue` expression has the type `!`. That is, when Rust computes the type of `guess`, it looks at both match arms, the former with a value of `u32` and the latter with a `!` value. Because `!` can never have a value, Rust decides that the type of `guess` is `u32`. This is also true for the `panic!` macro.
+
+- Finally, a never ending `loop` also has the `!` type.
+
+### Dynamically Sized Types and the `Sized` Trait
+- Dynamically Sized Types or DSTs or unsized types let us write code using values whose size we can know only at runtime.
+- An example of a DST in Rust is `str`. We can’t know how long the string is until runtime, meaning we can’t create a variable of type `str`, nor can we take an argument of type `str`.
+- **Rust needs to know how much memory to allocate for any value of a particular type, and all values of a type must use the same amount of memory**. This is why it is not possible to create a variable holding a dynamically sized type.
+- Therefore, Rust uses the `&str` type for string slices. A `&str` is _two_ values: the address of the `str` and its length. As such, we can know the size of a `&str` value at compile time: it’s twice the length of a `usize`
+- **The golden rule of dynamically sized types is that we must always put values of dynamically sized types behind a pointer of some kind.**
+
+- Every trait is a dynamically sized type we can refer to by using the name of the trait.
+- To work with DSTs, Rust provides the `Sized` trait to determine whether or not a type’s size is known at compile time. This trait is automatically implemented for everything whose size is known at compile time. 
+- In addition, Rust implicitly adds a bound on `Sized` to every generic function. That is, a generic function definition like this:
+```rust
+fn generic<T>(t: T) { }
+// is equivalent to
+fn generic<T: Sized>(t: T) { }
+```
+
+- By default, generic functions will work only on types that have a known size at compile time. However, you can use the following special syntax to relax this restriction:
+```rust
+fn generic<T: ?Sized>(t: &T) { } // Only available for Sized trait.
+```
+## [[Advanced Function and Closures]]

Advanced Function and Closures.md

@@ -0,0 +1,51 @@
+## Advanced Function and Closures
+### Function Pointers
+- Similar to how [[Closures|closures]] can be passed to functions, functions can also be passed to functions.
+- Functions coerce to the type `fn` (not the same as `Fn`). The `fn` type is called a *function pointer*.
+```rust
+fn add_one(x: i32) -> i32 {
+	x + 1
+}
+
+fn do_twice(f: fn(i32) -> i32, arg: i32) -> i32 {
+	f(arg) + f(arg)
+}
+
+fn main() {
+	let answer = do_twice(add_one, 5);
+}
+```
+- Unlike closures, `fn` is a type rather than a trait. Therefore, `fn` is used directly as the parameter type rather than declaring a generic type parameter with one of the `Fn` (closure) traits as the trait bound.
+- Function pointers implement all three of the closure traits (`Fn`, `FnMut`, and `FnOnce`), which means `fn` can always be passed as an argument for a function that expects a closure. An example of such a function is:
+```rust
+let list = vec![1, 2, 3];
+
+// covert elements to string using closure
+let list_strings = list.iter().map(|i| i.to_string()).collect();
+
+// using function pointers instead
+let list_strings = list.iter().map(ToString::to_string).collect();
+```
+- This can be a useful mechanism for generating enum variants. Recall that [[Defining an Enum|enum variants are themselves initializer functions]].
+```rust
+enum Status {
+	Value(u32),
+	Stop,
+}
+let list_statuses = (0u32..20).map(Status::Value).collect();
+```
+
+### Returning Closures
+- Since closures are represented by traits, they cannot be returned directly.
+- We have already seen one technique for [[Closures|returning closures]]. This is recalled in the code snippet below. Depending on the functionality implemented by the closure the trait can be `Fn`, `FnMut`, or `FnOnce`.
+```rust
+fn return_closure() -> impl Fn(i32) -> i32 { // can be FnMut or FnOnce
+	|x| x + 1
+}
+```
+- In situations where Rust is unable to understand how much size is required to store the closure, a [[Smart Pointers#Box Pointer Using `Box<T>` to Point to Data on the Heap|box pointer]] with a `dyn` keyword (similar to [[Trait Objects]]) is necessary.
+```rust
+fn returns_closure() -> Box<dyn Fn(i32) -> i32> {
+	Box::new(|x| x + 1)
+}
+```

Advanced Traits.md

@@ -0,0 +1,135 @@
+## Advanced Traits
+### Specifying Placeholder Types in Trait Definitions with Associated Types
+- _Associated types_ connect a type placeholder with a trait such that the trait method definitions can use these placeholder types in their signatures.
+- The implementor of a trait will specify the concrete type to be used instead of the placeholder type for the particular implementation. 
+- That way, we can define a trait that uses some types without needing to know exactly what those types are until the trait is implemented.
+```rust
+pub trait Iterator {
+	type Item;
+
+	fn next(&mut Self) -> Option<Self::Item>;
+}
+```
+- Although associated types look similar to generic types, they have some differences: With generics, types need to be annotated with each implementation. This implies that the same trait can be implemented multiple times, with the generic type being replaced with a concrete type each time. However, with associated types, we can only have one concrete type replace the associated type since there can only be one `impl` block with a unique method name. 
+- For the above reason, associated type also becomes a part of the trait's contract.
+
+### Default Generic Type Parameters and Operator Overloading
+- When we use generic type parameters, we can specify a default concrete type for the generic type.
+- This is done when declaring a generic type with the `<PlaceholderType=ConcreteType` syntax.
+- This technique is useful in operator overloading, which is used to customize the behavior of existing operators such as `+`. Operator overloading is done by implementing the traits associated with the operator. For example, the `Add` trait is defined as in the following example.
+```rust
+trait Add<Rhs=Self> {
+	type Output;
+	fn add(self, rhs: Rhs) -> Self::Output;
+}
+```
+- Since add provides a default type, it can be overloaded. The following example shows operator overloading for adding millimeters and meters together.
+```rust
+use std::ops::Add;
+
+struct Millimeters(u32);
+struct Meters(u32);
+
+impl Add<Meters> for Millimeters {
+	type Output = Millimeters;
+	fn add(self: other: Meters) -> Millimeters {
+		Millimeters(self.0 + (other.0 * 1000))
+	}
+}
+```
+- Default type parameters are used in two ways:
+	- To extend a type without breaking existing code.
+	- To allow customization in specific cases most users won't need.
+
+### Fully Qualified Syntax for Disambiguation
+- Sometimes, certain traits implemented on a data type may have the same names for the associated functions. In these situations disambiguation is necessary to ensure that the Rust compiler understands exactly which associated function is being called. 
+- The disambiguation needs to deal with two scenarios: when the associated function is a method, i.e., when it takes a self parameters, and when it is not a method.
+- Consider the following example with different trait methods having the same name.
+```rust
+trait Pilot {
+	fn fly(&self);
+}
+
+struct Human;
+
+impl Pilot for Human {
+	fn fly(&self) {
+		println!("This is your captain speaking");
+	}
+}
+
+impl Human {
+	fn fly(&self) {
+		println!("*waving arms furiously*");
+	}
+}
+
+fn main() {
+	let person = Human;
+	Pilot::fly(&person); // disambiguate fly for Pilot trait
+	person.fly(); // equivalent to Human::fly(&person)
+}
+```
+
+- The format of disambiguation used above will not work when the associated function is not a method, i.e., when it does not take a self parameter. In this case, it is impossible for Rust to tell which function of the many different data structures implementing the trait is being called. A fully qualified syntax is needed for discerning.
+```rust
+trait Animal {
+	fn baby_name() -> String;
+}
+
+struct Dog;
+
+impl Dog {
+	fn baby_name() -> String {
+		String::from("Spot")
+	}
+}
+
+impl Animal for Dog {
+	fn baby_name() -> String {
+		String::from("puppy")
+	}
+}
+
+fn main() {
+	println!("{}", Dog::baby_name());
+	println!("{}", <Dog as Animal>::baby_name()); // Animal::baby_name() will not work
+}
+```
+
+### Using Supertraits
+- A supertrait is a trait that uses the functionality of another trait in its own definition.
+- The following is an example of a supertrait `OutlinePrint` that formats the output of any data type implementing the `Display` trait. The format for specifying that the trait depends on another trait is
+```rust
+use std::fmt;
+
+trait OutlinePrint: fmt::Display { // syntax
+	fn outline_print(&self) {
+		// default implementation
+	}
+}
+```
+
+### Implementing External Traits on External Types
+- The orphan rule that states we’re only allowed to implement a trait on a type if either the trait or the type are local to our crate. 
+- It’s possible to get around this restriction using the _newtype pattern_, which involves creating a new type in a tuple struct.
+- As an example, let’s say we want to implement `Display` on `Vec<T>`, which the orphan rule prevents us from doing directly because the `Display` trait and the `Vec<T>` type are defined outside our crate. We can make a `Wrapper` struct that holds an instance of `Vec<T>`; then we can implement `Display` on `Wrapper` and use the `Vec<T>` value.
+
+```rust
+use std::fmt;
+
+struct Wrapper(Vec<String>); // work-around
+
+impl fmt::Display for Wrapper {
+    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
+        write!(f, "[{}]", self.0.join(", "))
+    }
+}
+
+fn main() {
+    let w = Wrapper(vec![String::from("hello"), String::from("world")]);
+    println!("w = {}", w);
+}
+```
+- The downside is `Wrapper` is a new type, so it doesn’t have the methods of the value it’s holding.
+- If we wanted the new type to have every method the inner type has, implementing the [[Smart Pointers#Treating Smart Pointers Like Regular References with the `Deref` Trait|Deref]]` trait.

Bipartite Graphs.md

@@ -0,0 +1,23 @@
+## Bipartite Graphs
+#graphTheory 
+
+- A graph $G$ is *Bipartite* if its vertices can be partitioned into two disjoint sets $L$ and $R$ such that:
+	- Every edge of $G$ connects a vertex $L$ to a vertex in $R$.
+	- No edge connects two vertices from the same set.
+- $L$ and $R$ are called the *parts* of $G$.
+![[Pasted image 20230724194906.png]]
+- **A graph is bipartite, $iff$ it has no cycles of odd length**.
+- A cycle graph with even vertices is a bipartite graph. Not true if number of vertices is odd.
+- Trees are bipartite as well.
+- A *Complete Bipartite Graph* $K_{L, R}$ is a bipartite graph in which all vertices of $L$ are connected to all vertices of $R$ and vice versa.
+
+### Matchings
+- A matching in a graph is a set of edges without common vertices.
+- A *maximal matching* is a matching which cannot be extended to a larger matching.
+- A *maximum* matching is a matching of the largest size.
+
+- In bipartite graphs, matchings can be used to find mapping solutions from one part to the other.
+
+### Hall's Theorem
+- **In a bipartite graph $G = (L \cup R, E)$, there is a matching which covers all vertices from L, $iff$ for every subset of vertices $S \subseteq L$, $$|S| \leq |N(S)|$$
+- Here, the *Neighborhood* $N(S)$ of $S$, a subset of vertices $S \subseteq V$ of graph $G = (V, E)$, is defined as the set of all vertices connected to at least one vertex in $S$.

Box Pointer.md

@@ -0,0 +1,37 @@
+## Using `Box<T>` to Point to Data on the Heap
+- Boxes allow storing data on the heap rather than the stack.
+- Boxes don't have performance overhead. They are most often used for:
+	- Types whose size can't be know at compile time.
+	- Ownership of large amounts of data that needs to be moved instead of copied.
+	- Owning a value of a type that implements a particular trait.
+- Creating a new box
+```rust
+fn main() {
+	let b = Box::new(5);
+	println!("{}", b);
+}
+```
+
+### Enabling Recursive Types with Boxes
+- Recursive types can have another value of the same type as a part of itself. 
+- Since the Rust compiler has no way of understanding how much space a recursive type takes up, these types can become an issue.
+- Using boxes can help break the recursive type definition into 
+- An example of a recursive type is a cons list, which is a data structure containing a nested pair. The first element in the pair is the value of the current item and the second element is the next value. 
+`(1, (2, (3, Nil)))`
+- A basic implementation in Rust would look like the following code. However, the compiler will throw an error since it is unable to assess the amount of space required for this data type.
+```rust
+enum List {
+	Cons(i32, List),
+	Nil,
+}
+```
+![[Pasted image 20230615161555.png]]
+
+- The workaround here would be store the value indirectly by storing a pointer to the value instead.
+```rust
+enum List {
+	Cons(i32, Box<List>),
+	Nil,
+}
+```
+![[Pasted image 20230615161921.png]]