X-Git-Url: https://git.ralfj.de/rust-101.git/blobdiff_plain/c25f3400060ea1a02f8fa9de69c39fd7b020e8a5..3449141636aeba89b2b768c8362a15fdd76c0a94:/src/part08.rs
diff --git a/src/part08.rs b/src/part08.rs
index e01a35b..2c6dfc5 100644
--- a/src/part08.rs
+++ b/src/part08.rs
@@ -17,18 +17,20 @@ fn overflowing_add(a: u64, b: u64, carry: bool) -> (u64, bool) {
//@ The reason for this is that many serious security vulnerabilities have been caused by integer overflows, so just assuming
//@ "per default" that they are intended is dangerous.
//@ If you explicitly *do* want an overflow to happen, you can call the `wrapping_add`
- //@ function (see [the documentation](http://doc.rust-lang.org/stable/std/primitive.u64.html#method.wrapping_add),
+ //@ function (see [the documentation](https://doc.rust-lang.org/stable/std/primitive.u64.html#method.wrapping_add),
//@ there are similar functions for other arithmetic operations). There are also similar functions
//@ `checked_add` etc. to enforce the overflow check.
- let sum = u64::wrapping_add(a, b);
+ let sum = a.wrapping_add(b);
// If an overflow happened, then the sum will be smaller than *both* summands. Without an overflow, of course, it will be
// at least as large as both of them. So, let's just pick one and check.
if sum >= a {
// The addition did not overflow.
// **Exercise 08.1**: Write the code to handle adding the carry in this case.
- unimplemented!()
+ let sum_total = sum.wrapping_add(if carry { 1 } else { 0 });/*@@*/
+ let had_overflow = sum_total < sum; /*@@*/
+ (sum_total, had_overflow) /*@@*/
} else {
- // The addition *did* overflow. It is impossible for the addition of the carry
+ // Otherwise, the addition *did* overflow. It is impossible for the addition of the carry
// to overflow again, as we are just adding 0 or 1.
(sum + if carry { 1 } else { 0 }, true) /*@*/
}
@@ -47,16 +49,15 @@ fn test_overflowing_add() {
// ## Associated Types
//@ Now we are equipped to write the addition function for `BigInt`. As you may have guessed, the `+` operator
-//@ is tied to a trait (`std::ops::Add`), which we are now going to implement for `BigInt`.
+//@ is tied to a trait (`std::ops::Add`), which we are going to implement for `BigInt`.
//@
-//@ In general, addition need not be homogeneous: For example, we could add a vector (in 3-dimensional
-//@ space, say) to a point. So when implementing `Add` for a type, one has to specify the type of
-//@ the other operand. In this case, it will also be `BigInt` (and we could have left it away, since that's the default).
+//@ In general, addition need not be homogeneous: You could add things of different types, like vectors and points. So when implementing
+//@ `Add` for a type, one has to specify the type of the other operand. In this case, it will also be `BigInt` (and we could have left it
+//@ away, since that's the default).
impl ops::Add for BigInt {
- //@ Besides static functions and methods, traits can contain *associated types*: This is a type
- //@ chosen by every particular implementation of the trait. The methods of the trait can then
- //@ refer to that type. In the case of addition, it is used to give the type of the result.
- //@ (Also see the [documentation of `Add`](http://doc.rust-lang.org/stable/std/ops/trait.Add.html).)
+ //@ Besides static functions and methods, traits can contain *associated types*: This is a type chosen by every particular implementation
+ //@ of the trait. The methods of the trait can then refer to that type. In the case of addition, it is used to give the type of the result.
+ //@ (Also see the [documentation of `Add`](https://doc.rust-lang.org/stable/std/ops/trait.Add.html).)
//@
//@ In general, you can consider the two `BigInt` given above (in the `impl` line) *input* types of trait search: When
//@ `a + b` is invoked with `a` having type `T` and `b` having type `U`, Rust tries to find an implementation of `Add` for
@@ -74,25 +75,29 @@ impl ops::Add for BigInt {
let mut result_vec:Vec = Vec::with_capacity(max_len);
let mut carry = false; /* the current carry bit */
for i in 0..max_len {
- // Compute next digit and carry. Store the digit for the result, and the carry for later.
let lhs_val = if i < self.data.len() { self.data[i] } else { 0 };
let rhs_val = if i < rhs.data.len() { rhs.data[i] } else { 0 };
+ // Compute next digit and carry. Then, store the digit for the result, and the carry for later.
+ //@ Notice how we can obtain names for the two components of the pair that `overflowing_add` returns.
let (sum, new_carry) = overflowing_add(lhs_val, rhs_val, carry); /*@*/
result_vec.push(sum); /*@*/
carry = new_carry; /*@*/
}
// **Exercise 08.2**: Handle the final `carry`, and return the sum.
- unimplemented!()
+ if carry { /*@@*/
+ result_vec.push(1); /*@@*/
+ } /*@@*/
+ BigInt { data: result_vec } /*@@*/
}
}
// ## Traits and borrowed types
-//@ If you inspect the addition function above closely, you will notice that it actually requires
-//@ *ownership* of its arguments: Both operands are consumed to produce the result. This is, of
-//@ course, in general not what we want. We'd rather like to be able to add two `&BigInt`.
+//@ If you inspect the addition function above closely, you will notice that it actually consumes ownership of both operands
+//@ to produce the result. This is, of course, in general not what we want. We'd rather like to be able to add two `&BigInt`.
// Writing this out becomes a bit tedious, because trait implementations (unlike functions) require full explicit annotation
-// of lifetimes. Make sure you understand exactly what the following definition says.
+// of lifetimes. Make sure you understand exactly what the following definition says. Notice that we can implement a trait for
+// a borrowed type!
impl<'a, 'b> ops::Add<&'a BigInt> for &'b BigInt {
type Output = BigInt;
fn add(self, rhs: &'a BigInt) -> Self::Output {
@@ -101,15 +106,28 @@ impl<'a, 'b> ops::Add<&'a BigInt> for &'b BigInt {
}
}
+// **Exercise 08.4**: Implement the two missing combinations of arguments for `Add`. You should not have to duplicate the implementation.
+
// ## Modules
//@ As you learned, tests can be written right in the middle of your development in Rust. However, it is
//@ considered good style to bundle all tests together. This is particularly useful in cases where
//@ you wrote utility functions for the tests, that no other code should use.
-// Rust calls a bunch of definitions that are grouped together a *module*. You can put definitions in a submodule as follows.
-mod my_mod {
- type MyType = i32;
- fn my_fun() -> MyType { 42 }
+// Rust calls a bunch of definitions that are grouped together a *module*. You can put the tests in a submodule as follows.
+//@ The `cfg` attribute controls whether this module is even compiled: If we added some functions that are useful for testing,
+//@ Rust would not bother compiling them when you just build your program for normal use. Other than that, tests work as usually.
+#[cfg(test)]
+mod tests {
+ use part05::BigInt;
+
+ /*#[test]*/
+ fn test_add() {
+ let b1 = BigInt::new(1 << 32);
+ let b2 = BigInt::from_vec(vec![0, 1]);
+
+ assert_eq!(&b1 + &b2, BigInt::from_vec(vec![1 << 32, 1]));
+ // **Exercise 08.5**: Add some more cases to this test.
+ }
}
//@ As already mentioned, outside of the module, only those items declared public with `pub` may be used. Submodules can access
//@ everything defined in their parents. Modules themselves are also hidden from the outside per default, and can be made public
@@ -126,25 +144,12 @@ mod my_mod {
//@ Modules can be put into separate files with the syntax `mod name;`. To explain this, let me take a small detour through
//@ the Rust compilation process. Cargo starts by invoking`rustc` on the file `src/lib.rs` or `src/main.rs`, depending on whether
//@ you compile an application or a library. When `rustc` encounters a `mod name;`, it looks for the files `name.rs` and
-//@ `name/mod.rs` and goes on compiling there. (It is an error for both of them to exist). You can think of the contents of the
+//@ `name/mod.rs` and goes on compiling there. (It is an error for both of them to exist.) You can think of the contents of the
//@ file being embedded at this place. However, only the file where compilation started, and files `name/mod.rs` can load modules
//@ from other files. This ensures that the directory structure mirrors the structure of the modules, with `mod.rs`, `lib.rs`
//@ and `main.rs` representing a directory or crate itself (similar to, e.g., `__init__.py` in Python).
-// For the purpose of testing, one typically introduces a module called `tests` and tells the compiler
-// (by means of the `cfg` attribute) to only compile this module for tests.
-#[cfg(test)]
-mod tests {
- //@ If we added some functions here that are useful for testing, Rust would not bother compiling
- //@ them when you just build your program for normal use. Other than that, tests work as usually.
- #[test]
- fn test_add() {
- let b1 = BigInt::new(1 << 32);
- let b2 = BigInt::from_vec(vec![0, 1]);
-
- assert_eq!(&b1 + &b2, BigInt::from_vec(vec![1 << 32, 1]));
- // **Exercise 08.4**: Add some more testcases.
- }
-}
+// **Exercise 08.6**: Write a subtraction function, and testcases for it. Decide for yourself how you want to handle negative results.
+// For example, you may want to return an `Option`, to panic, or to return `0`.
-//@ [index](main.html) | [previous](part07.html) | [next](main.html)
+//@ [index](main.html) | [previous](part07.html) | [raw source](https://www.ralfj.de/git/rust-101.git/blob_plain/HEAD:/workspace/src/part08.rs) | [next](part09.html)