Oh Rust. When I first saw the macro println!() I smiled. No longer must I write out the drawn out, dreadful, painful, hand cramping System.out.println() of Java or std::cout << [] << std::endl of C++. I was... happy. But there's a problem in Rust. Glaring, haunting, causing pain and suffering. Why isn't there a macro for reading io? I looked at creating custom macros but they looked even more daunting, so I might try that later on. So, my goal now is to make a function that can robustly read a line from io, and to make it readable. I'll make a "Hello Bot" (Type in your name, it says hello back) to test it. This is my attempt: main.rs
Let us walk through it.
For the first [now the second] time, we find ourselves using the use command. This tells the compiler that we want to use something that isn't directly available to us, for this case, stdin and Error from io. The function readln() is where the magic happens. First, I declare a mutable String called buffer, the next function call borrows a reference of it as a argument, and that's how you get the information back. Moving on. The match statement is for the return value of the function stdin().read_line(), which is a Result<usize, io::Error>. Why does it return the size of the string rather than the string itself and save itself from the &mut buffer parameter? No clue, it's kind of annoying. After a successful read, the buffer will probably have a "new line" character at the end, so we need to tuncate() the buffer by it's length - 1, then return the result Ok(buffer). After a unsuccessful read, the error will be returned (Just like read_line()), allowing the user of the function to choose what to do if it fails to read a line. And the main function isn't very important this time. It contains a simple request for a name, and a new call unwrap() which removes the Ok() or Err() wrapper, returning the inside value. You can do a match statement on readln() for true error handling. Again, thanks to Lokathor for the help. Thanks for reading - Gutrix. Edit history:
3 Comments
Source. Try the problem first if you want. /// Edited Below Ah. The Fizzbuzz problem. This question has struck a questionable and irrational fear in many programmers by its prevalence in job interview's questionnaires. It's simple question which is designed to make you overthink the problem. It has four simple requirements :
When I wrote the program in Rust (I've written it before in Java without much worries), I wanted it to be easily read and efficient. So, here is my attempt: Edited: Special thanks to reddit user l-arkham, for suggesting the usage of use FizzBuzzOptions::*; to bring the varients of the enumeration into a global scope, which allows for cleaner, more readable code. main.rs
Let us walk through it.
First thing is the enumeration FizzBuzzOptions, which (I think) helps the programmer handle the concepts of the requirements with a little abstraction. FizzBuzzOptions contains four enums, one for each requirement (FizzBuzz, Buzz, Fizz and Neither). Next is the function matching, which returns the appropriate FizzBuzzOption[s]. This is were the ordering of the if statements matters, as well as the fourth requirement's weird wording "multiples of both three and five", which means a multiple of fifteen. Whether x % 15 == 0 is true must be checked first before both x % 5 == 0 and x % 3 == 0. Lastly the main function, which contains the loop for x in 1..101 (Note: Rust lists .. are inclusive on the left, and exclusive on the right, so 1..5 means [1, 2, 3, 4]). The match statement calls matching for each x and compares the return to the list of options, picks the FizzBuzzOption[s] that matches (funny that), and executes the println!(). Nice and simple, and very easy to read. Some notes :
That's it. Thanks for reading. - Gutrix This is my first post so I'm going to set up some things here.
By default, this is the source code (which is in the file [project_name]/src/main.rs) : Riveting, I know. There are three important things to point out.
There, I think that's it. |
ArchivesCategories |