You can find the full source code here: https://github.com/caveofprogramming/rust/

To do this I’m implementing a data block recycling mechanism, so that after some initial buffering, the consumer passes used data blocks back to the producer, which fills in new data and adds them to the queue as soon as the consumer has read more data from the queue.

Here I’m using crossbeam 0.8, so my cargo.toml has this in it:

My imports look like this:

I’m using a bounded crossbeam channel. This is a channel which will only accept a specified number of data blocks. This is what constrains the speed of my producer; the producer cannot add new data blocks into the channel, once the channel’s full, until the consumer reads a block from the channel.

I’m using Duration here just to limit the speed of the consumer, to simulate processing video or audio at a fixed pace.

Then I have some definitions:

BLOCK_SIZE is the size of a single block of data. More typically it might be 512, 1024 or whatever.

N_BLOCKS is the size of the crossbeam channel.

Then BLOCK is the block definition itself. A block in this case is an array of BLOCK_SIZE elements, of type f64 (but you can use whatever type is useful). I wrap this in a Box smart pointer just so that these blocks exist on the heap, not the stack, and the channel actually contains references to them.

My two channels are created like this:

I have one channel for sending data to the consumer from the producer, and a second for ‘recycling’ the blocks by sending them from the consumer back to the producer.

In the producer I use send() to send the blocks and recv() to receive them. These methods both wait until (in the case of send()) there is space on the queue to send, or until (in the case of recv()) a block is available to be received.

The consumer is as follows. Now I’m using try_recv() to receive data. This returns immediately and will return an error if there’s no data to receive, so I’m relying on the producer successfully keeping up.

Then I use send to return the data block back to the producer. I think this should be OK, but we could also consider making the return queue unbounded (or just really large) to avoid any possible delay.

Finally, we wait for the threads to finish.

The output from running the program looks like this:

The most frustrating thing about Rust that I’ve found so far is the problem of how to refer to persistent entities that have to maintain their own state, across multiple threads.

In this video I’ll show you how to tackle the problem using Arc and Mutex.

However, this isn’t suitable for every situation.

For example, if your persistent entity happens to manage a collection of software instruments which have to be modified from a particular thread, while your audio thread separately has to read audio samples from those instruments, and the persistent entity must remain modifiable—then probably Mutexes aren’t the answer.

Locking mutexes in audio threads, or real-time threads generally, is widely considered a bad idea.

The best way I’ve found so far of dealing with this, after trying out a bunch of different things, is to use channels, which we covered earlier. These may not be fast enough to send one audio sample at a time, but we can send small blocks of data (maybe 512 samples) at a time, and recycle the blocks to and from the producer and consumer threads. That’s a topic for a future post!

Git repo: https://github.com/caveofprogramming/rust/

For many of us, writing Rust in an object-oriented style would seem natural, since we’re used to Java and Python and what-not.

But Rust does make you jump through a few hoops, for the sake of efficiency.

In this post we’ll see how to get object oriented behaviour in Rust, even when we want to be able to clone a vector of objects, which is sometimes very useful.

First let’s start with a simple trait.

Anything that implements this trait must have a get method that returns a float.

Now we’ll create a struct that implements the trait.

I’ve implemented the trait for Pi, and I’ve also added a constructor.

Now we can use Pi like this:

This prints:

I can also add Pi to vectors:

This works fine.

However, there’s a problem if I change the type of the vector to Vec<Value>, intending to put other things that implement the Value trait into the vector.

This doesn’t work:

The problem is that Rust, for efficiency, wants to know the size of everything you put in a vector, and here it doesn’t know that. We could create other things of difference sizes that implement Value, even at runtime, and put them in the vector.

The values in the vector will just be stored in contiguous blocks of memory, which can’t work if Rust doesn’t even know the size of them.

Furthermore, we don’t get the polymorphic behaviour we expect. We want the correct get method to be called, depending on what objects are found in the vector.

We can fix the first issue by storing an array of pointers, so that the actual objects are stored on the heap. To make polymorphism work, we need to use the dyn keyword.

We end up with the following working code:

By wrapping the vector elements in a Box and by using the dyn keyword, we get the result we expect.

Now suppose we want to clone the entire vector for some reason.

The following code still doesn’t work.

Rust knows how to clone the vector; it just doesn’t know how to clone

Box<dyn Value>

To fix this, we have to implement Clone for Box<dyn Value>.

The following implementation would work if we only ever expected Pi to implement Value (which is obviously a bit silly).

Now the program runs, but the problem is that when we clone a Vector of Value objects, we’re always going to get a Vector of Pi.

The solution is to give each implementation of Value a method which returns a box containing the cloned version of itself.

An easy way to make Pi cloneable is just to add #[derive(Clone)]at the top of it. But we could alternatively implement Clone for Pi however we want.

Now we add a method to the Value trait called clone_box.

Then we implement this for Pi.

Finally, we use this in our implementation of Clone for Box<dyn Value>.

Now our program works properly.

We can create something else that implements Value.

Now we can add Surprise to our vector and everything still works correctly.

When we run the program, the contents of both the original vector and the cloned vector behave appropriately.

Sending and Receiving Messages

Rust’s ownership rules can make it difficult to have multiple threads reading and writing to some data model.

Inter-thread messaging is a very elegant alternative.

For this example you need crossbeam-channel = “0.5” in your dependencies.

In this program I use crossbeam to create an “unbounded” channel, then I send a message consisting of the value 123 down the channel. At the other end of the channel, a receiver receives the value, and we print it.

Note: the channel is “unbounded” in the sense that we can send as many messages as we like, even if they haven’t been received yet. We can also create bounded channels that limit the number of messages that can be sent when they are not being received.

You can send vectors, structs, enums and complex data structures through a crossbeam channel.

The real value of this is:

• The sender and receiver do not have to exist in the same thread. They can be in different threads, and thread synchronisation problems are thereby avoided, since we’re not reading or writing shared data.

• With crossbeam you can clone the sender and receiver as many times as you want, and pass them around to different functions and to different threads, just as you like. A function or thread can take ownership of the clone, but it still refers to the same channel.

For example, you can have an “update engine” thread which solely deals with a data model, and fields requests for bits of data or applies updates to the model on the basis of messages sent to it.

We can also create a “bounded” channel.

This channel will only let us send messages one at a time; each message must be received before a new one can be sent. This channel is apparently a little more lightweight, and can be used to send replies to messages containing data.

I cover both in the video, and we also see how this looks in the (more realistic) context of using threads.

What is Dynamic Dispatch?

In object-oriented languages we can normally create subclasses of a superclass type, then have a variable of the superclass type which can be made to refer “dynamically” at runtime to whichever of the subclasses we like.

For example, we could have an Animal superclass, and Dog and Cat subclasses.

Dog and Cat are then kinds of Animal.

Suppose Animal has a speak() method. Dog and Cat then inherit this method, but they can override it, so that each has its own version of speak() with different functionality.

It’s then possible to write a program which, for example, asks the user what kind of Animal to create, and sets a variable of type Animal to refer to whatever they’ve chosen.

When the speak() method of this method is called, the correct version of it must then by called by the program at runtime. If the user chose to create a Dog, the Dog speak() method is called; if they chose a Cat, the Cat speak() method is called.

This is known as dynamic dispatch. The appropriate method is dynamically dispatched at runtime.

How This Works In Rust

Rust is a kind of semi-object-oriented language. It doesn’t have inheritance, so we can’t create a superclass object and then have subclasses of it.

However, it does have traits, which define functionality. So it is possible to have an Animal trait and then Dog and Cat structs which implement this trait.

Then we implement the trait for these classes. If Animal defines a speak() method, Dog and Cat must have one.

It is then possible, in Rust, to do dynamic dispatch, even just using ordinary references.

However, I ran into some problems with this when I wanted to create objects in the new() function of some other struct, as you’ll see in the video.

These problems can be solved using the reference counter, Rc.

In addition, when you specify a trait as the type of a variable, you must make the variable a reference and use the dyn keyword, which is specifically intended to allow dynamic dispatch, apparently. Otherwise your program won’t compile.

Dynamic Dispatch with Ordinary References

First let’s take a look at dynamic dispatch using only references.

Here’s our trait.

Dog and Cat are then just structs which implement this trait.

Give this, the following actually works perfectly well:

The problem is that this doesn’t work when we want to create the struct instances in a method, such as new(), and store references in struct fields, because then we end up with dangling references to objects that have gone out of scope.

Then we need reference counters, and I cover this in the video.

Let’s take a look here at a simple example of dynamic dispatch using reference counters.

Dynamic Dispatch with Reference Counters.

We’re going to need

at the top of the file.

Then we can do the following, which can also be made to work with struct methods and fields.

Why Don’t Plain References Work with Struct Fields?

This issue I had with plain references was that I wanted to have two struct fields referring to a Dog and a Cat then a third, “pet” that refers to one of the above, and I wanted to arrange this in a function called new() that’s associated with the struct.

One you’ve directly initialised a struct field with a Dog, for example, you can’t then make pet refer to that field via self, because self doesn’t exist yet.

You can’t create dog and cat local variables and just use references to those either, because then you’re left with dangling references.

Try it and you’ll see what I mean!

However, Rc fixes the problem.

If you need your objects to be mutable, you can use RefCell for interior mutability and use types like Rc<RefCell<dyn Animal».

If you need to pass objects between threads you could also consider

Arc<Mutex<dyn Animal»

or

Rc<RwLock<dyn Animal».

One major problem I’ve faced was, MVC in Rust just doesn’t work like I thought.

It appears you can’t really just have a model and some views, and then have a controller class that creates these and passes parts of the model to the views.

In this video I’ll show you the kinds of problems I ran into. Basically they come down to problems with borrowing; you can’t have two mutable references to the same thing at the same time, so your controller just freely pass around mutable links to views.

Passing different parts of a model to different views would require multiple mutable links to different parts of the same data structure, and I couldn’t find a way to get this to work.

However, it can be done, and the trick is to use RefCell (for interior mutability) and Rc (for multiple ownership).

Full code is here: https://github.com/caveofprogramming/rust/

I’ll probably also make videos on the software synth I’m working on, as soon as it can play an actual melody.

As programmers familiar with multithreading will know, you can’t just write to shared data using multiple different threads. Rust even stops you from doing this via its ownership system.

For example, in C (or practically any other language), even if two threads try to increment an integer, this creates problems, because even this isn’t an atomic (single step) operation.

Behind the scenes, the value of the integer gets copied to a register, incremented, and then copied back to the original memory location. Two threads doing this at the same time will sometimes both copy the original value before incrementing and copying back, and this means some increments will get skipped.

One way to deal with this is by using thread-safe integers, in this particular case. Rust has AtomicI32 for example.

Another, more general but also trickier method, is to use mutexes (locks) to ensure that two threads cannot write to the same variable at the same time.

The examples in this page are all built around the Rust documentation at https://doc.rust-lang.org/book/ch16-03-shared-state.html

A Simple Mutex Example

The new method of Mutex expects the initial value of the type that we want to protect.

In this example, a Mutex wraps an integer. To access the integer for writing, we have to lock the mutex.

The lock() method returns a Result which wraps either a MutexGuard or a PoisonError. MutexGuard is a kind of smart pointer which implements the Deref trait, so we can dereference it to get at the actual value.

The key point about a mutex is that two threads (or the same thread) cannot lock it twice at the same time.

The following program just hangs, because the main thread waits indefinitely on the second lock attempt. It’s waiting for the lock to be unlocked by another thread, which never happens.

Using Mutexes to Increment a Value

In the following program I create 10 threads and, in each of them, I increment the value guarded by the mutex.

When you try to do this naively, the first problem that comes up is you cannot access the mutex variable from the closure, because then the closure code might outlive the variable.

You are forced to add move to the closer declaration, to move the variable into the closure. But then, you can’t move it into subsequent closures in further iterations of the loop.

You can try to fix this by using Rc, with clone, but then the problem is that Rc isn’t threadsafe, so you still get an error and the code won’t compile.

However, if we swap Rc for Arc (atomic reference counter), which is thread safe, the code now works and finally prints 10.

Creating a Thread

The following program spawns a thread and runs some code in it.

The program thus runs two threads: the main thread, and one additional thread. The sleep (which pauses the main thread here) is needed because otherwise the main thread will exit, destroying all spawned threads, before the text can be printed.

Waiting for Threads to Finish

Instead of pausing, which necessitates having to try to guess how long we need for the spawned thread to finish, or else just wait excessively long, we can wait till a thread finishes.

The unwrap here causes a panic if the thread can’t be run, because the join() function, which waits for a thread to finish, returns a Result.

Thread Interleaving

To prove that threads run concurrently, which is the point of them, we can run two threads at the same time.

In the following code, a pause is used within the loops because otherwise, one thread might finish before the other can start. There’s no guarantee about which thread runs first.

Alternatively, we can spawn two new threads and print output from those. In that case, we’d better wait for both of them to finish.

In both cases, the output ends up interleaved.

Accessing Variables at the Enclosing Scope

The following code does not compile. We are not allowed to access the variable v within the closure, because if this code were to actually compile, v could be dropped before the thread has finished with it.

The solution is to add the move keyword to the closure. This ensure local variables access within the closure are moved, so that the closure takes ownership. Drop after the thread code is then not allowed

This code compiles and works fine.

Passing Messages

When two or more threads try to modify the same variable, problems typically ensue, because the work of one thread conflicts with the other.

But this can’t easily happen in Rust, because a thread has to take ownership of a variable to be able to modify it.

There are various alternative ways of communicating between threads where needed, instead of multiple threads modifying the same variables.

One of these is to make use of messages.

The following code creates a channel that can be used to communicate between threads. mpsc stands for “multiple producer, single consumer”.

That is, multiple threads can send data down the channel, and one thread can consume it.

tx is the “transmitter” and rx the “receiver”.

The send method is used to send data, and the recv (short for receive) method is used to receive it.

Multiple Senders

In this code, minimally adapted from the Rust documentation, multiple receivers send to a channel.

Note:

• The transmitter is cloned. Otherwise it would be unavailable after moving into the first sender thread code.

• The senders send text with one-second delays. The receiver actually blocks until data is available, so the receiver gradually spits out the transmitted strings.

• The receiver thread is using the receiver as an iterator, rather than calling recv().

The order of the output may vary.

Code on GitHub: https://github.com/caveofprogramming/rust/

RefCell

RefCell (std::cell::RefCell) is another kind of smart pointer.

It implements the “interior mutability” pattern. This means that you can mutate the contents of a RefCell using an immutable reference.

Borrowing rules with RefCell are enforced at runtime, not compile time.

RefCell provides two functions that allow you to get references to its contents: borrow() and borrow_mut().

In the following example, I wrap an integer in a RefCell, print it using borrow() and alter it using borrow_mut().

My Descent Into Madness

At this point I found myself facing a difficult question: what is this actually for?

I read somewhere that it might be useful for implementing tree or other structures, where you want to be able to alter the nodes.

You might use Rc to implement multiple ownership of the nodes, so that one node can be in multiple places and still get cleaned up at the right time.

But Rc does not allow you to mutate its contents, so you can wrap a RefCell with an Rc.

This sounds fine and I was able to get Microsoft Copilot to implement such a program (I couldn’t quite manage it myself), but the unsatisfactory thing is that the resulting API isn’t very clean.

It ends up being necessary to call borrow methods on the nodes before calling their insert methods.

When I tried to get Copilot to implement something more to my liking, including nodes that contain strings, it couldn’t seem to manage it, producing code over and over again that just didn’t compile.

The Problem

Part of the problem, I realised, was that I wasn’t clear about what I actually wanted. I can’t have nodes that are owned by variables in main() but then somehow also have multiple owners within some structure, unless those nodes are actually created as Rc smart pointers.

No matter what I try, it becomes necessary to expose smart pointer methods outside of my desired API.

Another problem is, if nodes in a tree can appear at different points in a tree, those nodes will also have pointers to other nodes that are repeated within the tree, and potentially you’ll create an infinite recursive tree.

Solution, Sort Of

Eventually I came up with the program outlined in the video, which you can also find on GitHub.

This consists of nodes formed from Data structs, connected by Connector structs.

It’s possible to connect them into a kind of triangle, or loop, where the last in the chain connects to the first.

Because RefCell is used to refer to the nodes, they can be seamlessly swapped out, even though immutable Rc smart pointers are used to refer to them.

Consider a tree structure, where every node in the tree may have child nodes.

A node may appear multiple times at different points in the tree.

How do we ensure that every node is cleaned up (dropped) eventually, but is never dropped as long as at least one other node still refers to it?

This can be accomplished using reference counting.

Example Struct

I will use the following struct, representing person data. I’ve implemented the Drop trait so that we can see exactly when a Person object is dropped.

Managing the Object

We can use std::rc::Rc to initially own the object.

The object then has a reference count of 1.

After this we can create more variables that own the object, incrementing the reference count.

The object will only be cleaned up and drop() called when all of these references have been dropped or have gone out of scope.

We can drop these references manually if desired, in any order.

The Rc object keeps a count of how many references still refer to the object, and the object gets dropped when there are none left.

If a Rust type implements the Drop trait, the drop method of any object of that type will be called automatically when the variable that owns it goes out of scope.

This can be used for cleanup, e.g. terminating database connections, freeing memory.

Here’s a struct called Data which stores a single value.

We can implement the Drop trait like this:

Here I’ve made the drop function just output some text.

Now drop() is called whenever the owner of any object of type Data goes out of scope.

For example, the following code outputs Dropping 0, because here the owner of the Data struct immediately goes out of scope right after it’s created, at the closing bracket.

As a precaution against cleanup code being called twice, the drop method cannot be called directly, but you can invoke it using the std::mem::drop function (which is part of the prelude so no need for an import).

Code on Github: https://github.com/caveofprogramming/rust/

Why Can Box Be Dereferenced?

The following code dereferences Box with * to get the value out of Box. This is what we’ll look at here. This is accomplished by implementing the Deref trait.

Actually, with Box, the following code also works and prints the value 5, even without the dereference operator.

This second kind of behaviour apparently depends on special compiler support for deref coercion for types in the standard library, where values are automatically dereferenced. This isn’t going to work with our own types, although we could make it work by implementing the Display trait.

A Tuple Struct

We start with a simple tuple struct. Tuple structs are like structs except the fields aren’t named.

The following code defines a tuple struct that can hold one integer value. We create a tuple struct and then print its value, using .0 to access its first field.

We can make this able to handle any type via generics.

Now the type T is inferred by the compiler, and we can successfully handle a float.

It is possible to explicitly define the type of thing that the tuple struct works with like this:

Adding a Constructor-Like Method

We can add a new function that allows us to construct these tuple structs.

The name new here is only a convention.

The first <T> after impl specifies that T is a type that can be used in the rest of the definition. The <T> after Value says that Value is actually a generic type and is going to work with whatever T is.

Now we can create a Value like this:

But we still can’t use * to get the numeric or other value out of our Value struct.

To make that work we need to implement the Deref trait.

Implementing Deref

We can implement Deref like this:

The type Target = T here provides an associated type, T, that will be returned by the dereference operator.

We can now do this:

Implicit Deref Coercion

Although we can’t pass a Value to println! without dereferencing it, there are circumstances under which Rust will actually dereference it as many times as necessary to get a value of the right type, and this happens at compile time.

Suppose we define a function like this:

And we have a Value containing an i32:

We still cannot pass this value directly to test(), but if we pass a reference to a Value containing an i32, Rust will dereference it twice to coerce the Value into an i32.

This actually works!

Code: https://github.com/caveofprogramming/rust/

The following leans heavily on the examples in the Rust documentation.

I’ve tried to enlarge on the existing examples and explanation.

Storing on the Heap

In Rust, Box can be used to store values on the heap instead of the stack.

For example, in this code, the value of the integer is stored on the stack:

A slight change, to use Box, means the value is stored on the heap instead:

In both cases the output is:

Even though type of value in the second example is now Box<i32>, Box implements the Deref trait, which means when we access value it is automatically dereferenced without need for any new syntax.

Storing a single integer on the heap seems a bit useless, but we can also store other things on the heap, like large arrays. The following code creates an array on the stack; it has 100 elements but could of course have many more.

With a slight adjustment, the array exists on the heap instead:

Recursive Types

The following code creates an enum called List, with two variants: A and B.

It’s possible to associate one or more values with each variant. These can then be extracted using a match.

In this case, the match extracts both values associated with the variant A as a tuple. This code prints:

In Lisp, it’s possible to create a list using a “cons cell”, which is a pair of two values, not unlike our enum. “Cons” comes from the word “construct”. This can be done via a recursive definition.

You might think the equivalent in Rust would be as follows:

(This does not work)

The error when we compile this code is:

The problem is apparently that Rust cannot determine the size of a List. However, if we insert a Box in there, this does work. Since the content of the Box is stored on the heap, the size of the enum now only involves the size of a pointer to that data, not the data itself.

We can also change the names of the variants to something inspired by Lisp.

The size of the List comes out at 16 bytes, as against 8 bytes for just a Box.

This size is determined by several factor: the size of the largest variant, data associated with the variants, and the size of the discriminant that specifies which variant is being used (one byte for up to 256 variants).

In this video I’ve put together a program that parses command-line args (a string and an integer) using iterators, rather than collecting them in a vector.

You can see the full program via the GitHub link above, or in the video.

I’ve used the following techniques in the program.

Retrieving Arguments

You can specify program arguments when you run via cargo like this:

cargo run — hello to you

hello, to and you become arguments to the program being run.

To retrieve these arguments in the program we can use:

args gets set to an object which implements the Iterator trait.

Passing Arguments to a Function

To pass this variable to a function, we can specify that the argument implements the Iterator trait, and specifically, an Iterator over strings.

next() actually returns an Option<T>, so we have to unwrap it to get at the actual string argument.

Since the first argument is always the name of the program, and my program is called “iterator”, this prints

When I run it with cargo.

Unwrapping with Match and Returning a Result

Here I’ve written some code that retrieves the first user-supplied argument and returns it from a function, in the Ok value of the Result enum.

If there’s no such argument, the function returns Err.

The Ok value wraps a String, because it’s supplied by the user via the command line.

The Err value returns a &str, because it’s hardcoded into the program. It has a lifetime of ‘static, for the same reason.

Retrieving a Numerical Argument

The following function does the same thing, except it expect the argument (now an age) to be an unsigned integer.

As before, next() gets us the next argument from the args iterator. This returns a Option<T>, having the values either Some or None.

ok_or() then translates the Option<T> into a Result<T>. If the Option was set to Some, it gets the value from Some and wraps it with Ok. Otherwise it wraps the supplied message with Err.

The question mark after ok_or() then returns from the get_age_arg() function with the Err if no argument could be retrieved, otherwise it unwraps the value contained in Ok.

parse::<u32>() then tries to parse the string argument into an unsigned 32-bit integer. This returns a Result: Ok wraps the value if the parse was successful, otherwise Err wraps an error value.

However, the error value isn’t just a &str, so we can’t add a question mark to just return from the function in case of error.

Instead, we use map_err() with a closure to translate the Err into an Err containing a string.

That’s now compatible with the return type of get_age_args(), so we can use a question mark to return from the function in case of an error.

Github: https://github.com/caveofprogramming/rust

Iterators, and the Iterator Interface

The iter() method of vectors in Rust returns an immutable iterator. This is an instance of the Iter struct and it implements the Iterator trait. This means we can use it to iterate over the vector.

The Iterator trait defines various methods, including next(). We can use this to retrieve items one at a time.

Prints:

In the code above, iter has to be declared mut, since it stores its position and we change it by calling next. for does this behind the scenes.

The Iterator trait defines various methods, including count() and sum()

In the above code, we have to declare the type of the things being iterated over somewhere; either after sum() or else on the variable itself.

We can use iter_mut() instead of iter() to get a mutable reference to the items in the vector. Then we can dereference the reference with * to change the item.

number here is not an actual number, but a mutable reference to one, so it doesn’t have to be declared with mut.

Iterator Adapters

Iterator methods that wind the iterator forwards by calling next are called consuming adapters. There are also iterator adapters that don’t consume the iterator.

For example, we can use map with a closure to change the items in the iterator.

Prints:

The Vec<_> here is needed. The underscore tells Rust to infer the type of the items in the vector.

Another example is the filter method, which creates a filtered copy of the vector.

Prints:

Git repo: https://github.com/caveofprogramming/rust/

Basic Closures

The thing that the Rust docs call closures, at least as far as I can tell, are the same things that programmers in other languages call lambda expressions: simply-defined anonymous functions that can access the scope in which they’re defined.

Here’s an example of a closure that, when called, prints “Hello”.

The two vertical pipes provide a space where parameters can be defined.

This closure adds two numbers together. The expression provides the return value.

It is possible to supply explicit parameter and return types.

Now I’m forced to add in braces to get it to work.

Otherwise, the parameter and return types are inferred when you first call the closure.

Closure Type Inference

Here, I define a closure and pass an int to it. When I try to call it again with a float, I get an error, because the first call caused i32 to be inferred for the type of the parameter.

Accessing Local Variables within Closures

Closures can access variables in the enclosing scope (hence the name “closure”), either by immutable borrow, mutable borrow or by taking ownership.

This closure performs an immutable borrow:

Here’s a closure that performs a mutable borrow:

Passing Closures to Functions

To define a function parameters type that will accept a function or other closure, we can use the fn keyword.

This function accepts three parameters: a function that accepts two integers and returns an integers, and two integers.

We can call it like this:

This prints “11”.

I won’t provide a writeup for this, because it’s a lot of code, and the Rust docs already comments on it extensively.

However here’s my finished minigrep program: https://github.com/caveofprogramming/rust/

And here are the corresponding pages from the Rust docs: https://doc.rust-lang.org/book/ch12-00-an-io-project.html

Github repository: https://github.com/caveofprogramming/rust

A Library Function That Calculates Factorials

It’s only possible to create tests in Rust for library code.

Therefore I’m going to create a library called ‘numerical’ like this:

cargo new numerical --lib

Now, since I’d like to also use the library code from a binary, I create a file called main.rs in the src folder, and add a main function into it.

It’s now possible to run this code as a binary executable with cargo run, or to just build the binary and the library using cargo build. Since the library includes dummy tests, we can run the tests with cargo test.

I’ll create another file in src/ called numeric.rs, and in there I’ll add a recursive function for calculating factorials.

Then I’ll make main.rs use the factorial function. I also need to make lib.rs load the numeric module.

We now have the following files:

main.rs:

lib.rs:

numeric.rs:

When I run this as a binary with cargo run, the output is 6.

Adding Unit Tests

According to the documentation, unless my brain has failed to grasp it properly, unit tests (tests that test individual units of the code such as functions) are typically placed in the same file where they are defined.

Therefore I’ll add a submodule into numeric.rs.

The #[cfg(test)] annotation on the submodule says that it should be loaded when cargo is run with test configuration, i.e. when cargo test is executed.

Individual unit tests are marked with #[test].

assert_eq! and assert! can be used to check the results of tests.

.We can run this test with cargo test, and it passes.

Multiple Tests

I’ve modified the test submodule by adding two more tests:

One of these tests is marked with #[ignore]. It won’t be run by default.

To run all tests, including the ignored tests, we can use:

cargo test -- --include-ignored

To run only the ignored tests, we can use:

cargo test -- --ignored

Testing Panic

We can test code that should panic using the should_panic specification. This optionally allows us to specify a substring that should be found in the panic message.

Here I’ve artificially added a panic! into the test itself, which would normally be expected to come from the code under test. Unless a panic occurs and the text contains the string “bad”, this test fails.

Returning Result

Instead of using assert! or assert_eq! it’s also possible to return a Result. The following test passes if it returns Ok and fails if it returns Error.

Integration Tests

The above tests are all unit tests, that test software units. It’s also possible to create integration tests: tests external to a library that test how the library functions work together.

I’ve created a file called test_numeric.rs (but the name isn’t important) and put it in a folder called tests/, parallel to src/.

In this case there’s no need to put the tests in a submodule, and the library functions can be imported normally, using the package name.

test_numeric.rs (in a tests folder parallel to src/):

These tests will also run automatically when you run cargo test.

Git repository: https://github.com/caveofprogramming/rust/

Functions and Lifetimes

In rust, the following program doesn’t compile unless we move the println!() inside the brackets

All references have a lifetime, and in this case, the variable y is dropped at the closing bracket, meaning the reference x doesn’t “live long enough” to be printed outside the brackets.

Lifetime parameters are generic parameters and begin with an apostrophe. Usually single lower-case letters are used to name them.

The most common function of them is to connect the lifetime of references returned from functions to the lifetimes of arguments upon which they depend.

The following program, which just returns its argument, compiles fine.

The generic parameter ‘a is a lifetime annotation. It specifies that the returned reference lives as long as the s parameter.

In this case, the program also compiles without the ‘a lifetime specification, because this situation is simple enough for the Rust compiler to not require it.

In the following program, the lifetime annotations are necessary for the longest function to compile.

Here’s my understanding of this program: the generic parameter ‘a is inferred from the arguments passed to the function. ‘a will end up specifying that the lifetime of the returned reference is as long as the shortest lifetime of any of the input parameter references.

Struct Lifetime Parameters

Structs can also contain references, but then you also need to specify lifetime parameters.

Starfields

In the video I also demonstrate that you can create an animated starfield program using Microsoft Hotspot, and with a few slight tweaks no warnings even appear when you compile it!

Github: https://github.com/caveofprogramming/rust/

Using Traits in Return Types

I created a file called book.rs and put a struct in it:

The struct and its fields all have to be public if I want to use it outside of the file it’s in.

To make the Rust compiler process this file, I need a mod statement in main.rs to tell Rust about the file.

I also want to be able to use the new Book type I’ve created in main.rs, so I also add a use statement:

I want to create a couple of traits that my book will implement, so I put those in a file I called details.rs. Here is the complete details.rs:

I load details.rs by adding a mod statement to main.rs:

Now in book.rs I can say that Book implements these traits, by importing the traits and then adding implementations. Here is the complete book.rs. Notice I had to import the traits via absolute paths, not relative paths.

Now in main.rs I can define a function that returns an object that implements both traits:

I can then use this to obtain a book object, and since I know it must have methods author() and title(), I can use those to print details. Here is the complete main.rs:

Traits as Function Parameters

A very similar syntax can be used to specify that a function argument must implement certain traits, again using the impl keyword.

This function accepts a reference to an object that implements the Author and Title traits. If only one interface needs to be implemented, of course neither the + nor the brackets after the & are needed.

This is apparently syntactic sugar for a slightly different syntax:

There is another syntax which is designed to be helpful if you need to specify lots of interfaces or have lots of generic parameter types: