X-Git-Url: https://git.ralfj.de/rust-101.git/blobdiff_plain/b60c82e9d3b03aa36484c1ff68f34f4e78862d46..ab7f9b241429bd675b437d2437799de75d2f409b:/src/part08.rs diff --git a/src/part08.rs b/src/part08.rs index 4ef9d74..c18cbeb 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) /*@*/ } @@ -55,7 +57,7 @@ fn test_overflowing_add() { 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).) + //@ (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 @@ -82,17 +84,20 @@ impl ops::Add for BigInt { 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 +// ## Traits and reference types //@ 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. Notice that we can implement a trait for -// a borrowed type! +// a reference type! impl<'a, 'b> ops::Add<&'a BigInt> for &'b BigInt { type Output = BigInt; fn add(self, rhs: &'a BigInt) -> Self::Output { @@ -113,7 +118,9 @@ impl<'a, 'b> ops::Add<&'a BigInt> for &'b BigInt { //@ 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 { - #[test] + use part05::BigInt; + + /*#[test]*/ fn test_add() { let b1 = BigInt::new(1 << 32); let b2 = BigInt::from_vec(vec![0, 1]); @@ -145,4 +152,4 @@ mod tests { // **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](part09.html) +//@ [index](main.html) | [previous](part07.html) | [raw source](workspace/src/part08.rs) | [next](part09.html)