@@ -260,8 +260,8 @@ name = "vecs2"
260260path = " exercises/vecs/vecs2.rs"
261261mode = " test"
262262hint = """
263- Hint 1: `i ` is each element from the Vec as they are being iterated. Can you try
264- multiplying this?
263+ Hint 1: `element ` is each element from the Vec as they are being iterated. Can you
264+ try multiplying this?
265265
266266Hint 2: For the first function, there's a way to directly access the numbers stored
267267in the Vec, using the * dereference operator. You can both access and write to the
@@ -287,23 +287,24 @@ Also: Try accessing `vec0` after having called `fill_vec()`. See what happens!""
287287[[exercises ]]
288288name = " move_semantics2"
289289path = " exercises/move_semantics/move_semantics2.rs"
290- mode = " compile "
290+ mode = " test "
291291hint = """
292- So, `vec0` is passed into the `fill_vec` function as an argument. In Rust,
293- when an argument is passed to a function and it's not explicitly returned,
294- you can't use the original variable anymore. We call this "moving" a variable .
295- Variables that are moved into a function (or block scope) and aren't explicitly
296- returned get "dropped" at the end of that function. This is also what happens here .
297- There's a few ways to fix this, try them all if you want :
298- 1. Make another, separate version of the data that's in `vec0` and pass that
292+ When running this exercise for the first time, you'll notice an error about
293+ "borrow of moved value". In Rust, when an argument is passed to a function and
294+ it's not explicitly returned, you can't use the original variable anymore.
295+ We call this "moving" a variable. When we pass `vec0` into `fill_vec`, it's being
296+ "moved" into `vec1`, meaning we can't access `vec0` anymore after the fact .
297+ Rust provides a couple of different ways to mitigate this issue, feel free to try them all :
298+ 1. You could make another, separate version of the data that's in `vec0` and pass that
299299 to `fill_vec` instead.
3003002. Make `fill_vec` borrow its argument instead of taking ownership of it,
301- and then copy the data within the function in order to return an owned
302- `Vec<i32>`
303- 3. Make `fill_vec` *mutably* borrow a reference to its argument (which will need to be
304- mutable), modify it directly, then not return anything. Then you can get rid
305- of `vec1` entirely -- note that this will change what gets printed by the
306- first `println!`"""
301+ and then copy the data within the function (`vec.clone()`) in order to return an owned
302+ `Vec<i32>`.
303+ 3. Or, you could make `fill_vec` *mutably* borrow a reference to its argument (which will need to be
304+ mutable), modify it directly, then not return anything. This means that `vec0` will change over the
305+ course of the function, and makes `vec1` redundant (make sure to change the parameters of the `println!`
306+ statements if you go this route)
307+ """
307308
308309[[exercises ]]
309310name = " move_semantics3"
@@ -905,67 +906,6 @@ The fold method can be useful in the count_collection_iterator function.
905906For a further challenge, consult the documentation for Iterator to find
906907a different method that could make your code more compact than using fold."""
907908
908- # THREADS
909-
910- [[exercises ]]
911- name = " threads1"
912- path = " exercises/threads/threads1.rs"
913- mode = " compile"
914- hint = """
915- `JoinHandle` is a struct that is returned from a spawned thread:
916- https://doc.rust-lang.org/std/thread/fn.spawn.html
917-
918- A challenge with multi-threaded applications is that the main thread can
919- finish before the spawned threads are completed.
920- https://doc.rust-lang.org/book/ch16-01-threads.html#waiting-for-all-threads-to-finish-using-join-handles
921-
922- Use the JoinHandles to wait for each thread to finish and collect their results.
923- https://doc.rust-lang.org/std/thread/struct.JoinHandle.html
924- """
925-
926- [[exercises ]]
927- name = " threads2"
928- path = " exercises/threads/threads2.rs"
929- mode = " compile"
930- hint = """
931- `Arc` is an Atomic Reference Counted pointer that allows safe, shared access
932- to **immutable** data. But we want to *change* the number of `jobs_completed`
933- so we'll need to also use another type that will only allow one thread to
934- mutate the data at a time. Take a look at this section of the book:
935- https://doc.rust-lang.org/book/ch16-03-shared-state.html#atomic-reference-counting-with-arct
936- and keep reading if you'd like more hints :)
937-
938-
939- Do you now have an `Arc` `Mutex` `JobStatus` at the beginning of main? Like:
940- `let status = Arc::new(Mutex::new(JobStatus { jobs_completed: 0 }));`
941- Similar to the code in the example in the book that happens after the text
942- that says "We can use Arc<T> to fix this.". If not, give that a try! If you
943- do and would like more hints, keep reading!!
944-
945-
946- Make sure neither of your threads are holding onto the lock of the mutex
947- while they are sleeping, since this will prevent the other thread from
948- being allowed to get the lock. Locks are automatically released when
949- they go out of scope.
950-
951- If you've learned from the sample solutions, I encourage you to come
952- back to this exercise and try it again in a few days to reinforce
953- what you've learned :)"""
954-
955- [[exercises ]]
956- name = " threads3"
957- path = " exercises/threads/threads3.rs"
958- mode = " compile"
959- hint = """
960- An alternate way to handle concurrency between threads is to use
961- a mpsc (multiple producer, single consumer) channel to communicate.
962- With both a sending end and a receiving end, it's possible to
963- send values in one thread and receive them in another.
964- Multiple producers are possible by using clone() to create a duplicate
965- of the original sending end.
966- See https://doc.rust-lang.org/book/ch16-02-message-passing.html for more info.
967- """
968-
969909# SMART POINTERS
970910
971911[[exercises ]]
@@ -1028,6 +968,67 @@ Check out https://doc.rust-lang.org/std/borrow/enum.Cow.html for documentation
1028968on the `Cow` type.
1029969"""
1030970
971+ # THREADS
972+
973+ [[exercises ]]
974+ name = " threads1"
975+ path = " exercises/threads/threads1.rs"
976+ mode = " compile"
977+ hint = """
978+ `JoinHandle` is a struct that is returned from a spawned thread:
979+ https://doc.rust-lang.org/std/thread/fn.spawn.html
980+
981+ A challenge with multi-threaded applications is that the main thread can
982+ finish before the spawned threads are completed.
983+ https://doc.rust-lang.org/book/ch16-01-threads.html#waiting-for-all-threads-to-finish-using-join-handles
984+
985+ Use the JoinHandles to wait for each thread to finish and collect their results.
986+ https://doc.rust-lang.org/std/thread/struct.JoinHandle.html
987+ """
988+
989+ [[exercises ]]
990+ name = " threads2"
991+ path = " exercises/threads/threads2.rs"
992+ mode = " compile"
993+ hint = """
994+ `Arc` is an Atomic Reference Counted pointer that allows safe, shared access
995+ to **immutable** data. But we want to *change* the number of `jobs_completed`
996+ so we'll need to also use another type that will only allow one thread to
997+ mutate the data at a time. Take a look at this section of the book:
998+ https://doc.rust-lang.org/book/ch16-03-shared-state.html#atomic-reference-counting-with-arct
999+ and keep reading if you'd like more hints :)
1000+
1001+
1002+ Do you now have an `Arc` `Mutex` `JobStatus` at the beginning of main? Like:
1003+ `let status = Arc::new(Mutex::new(JobStatus { jobs_completed: 0 }));`
1004+ Similar to the code in the example in the book that happens after the text
1005+ that says "We can use Arc<T> to fix this.". If not, give that a try! If you
1006+ do and would like more hints, keep reading!!
1007+
1008+
1009+ Make sure neither of your threads are holding onto the lock of the mutex
1010+ while they are sleeping, since this will prevent the other thread from
1011+ being allowed to get the lock. Locks are automatically released when
1012+ they go out of scope.
1013+
1014+ If you've learned from the sample solutions, I encourage you to come
1015+ back to this exercise and try it again in a few days to reinforce
1016+ what you've learned :)"""
1017+
1018+ [[exercises ]]
1019+ name = " threads3"
1020+ path = " exercises/threads/threads3.rs"
1021+ mode = " compile"
1022+ hint = """
1023+ An alternate way to handle concurrency between threads is to use
1024+ a mpsc (multiple producer, single consumer) channel to communicate.
1025+ With both a sending end and a receiving end, it's possible to
1026+ send values in one thread and receive them in another.
1027+ Multiple producers are possible by using clone() to create a duplicate
1028+ of the original sending end.
1029+ See https://doc.rust-lang.org/book/ch16-02-message-passing.html for more info.
1030+ """
1031+
10311032# MACROS
10321033
10331034[[exercises ]]
@@ -1170,4 +1171,4 @@ name = "as_ref_mut"
11701171path = " exercises/conversions/as_ref_mut.rs"
11711172mode = " test"
11721173hint = """
1173- Add AsRef<str> as a trait bound to the functions."""
1174+ Add AsRef<str> or AsMut<u32> as a trait bound to the functions."""
0 commit comments