I am trying to figure out on my own reading through documentation, but with no luck on how to convert this Go function into Rust:
func main() {
cards := []string{"Ace of Diamonds", newCard()}
cards = append(cards, "Six of Spades")
fmt.Println(cards)
}
func newCard() string {
return "Five of Diamonds"
}
This is not correct, at least the cards.append I know is wrong:
fn main() {
let mut cards: [&str; 2] = ["Ace of Diamonds", new_card()];
let mut additional_card: [&str; 1] = ["Six of Spades"];
cards.append(additional_card);
println!("cards")
}
fn new_card() -> &'static str {
"Five of Diamonds"
}
You can't. like in Go, Rust arrays are fixed size.
The type [&str; 2] in Rust is roughly equivalent to [2]string in Go, which you also can't append to.
The closest to a Go slice you can get to in Rust is a Vec which you can use like this:
fn main() {
let mut cards = vec!["Ace of Diamonds", new_card()];
let additional_cards: [&str; 2] = ["Six of Spades", "Seven of Clubs"];
// for anything that implements `IntoIter` of cards
cards.extend(additional_cards);
// or for a single card only
cards.push("Three of Hearts");
println!("{cards:?}")
}
fn new_card() -> &'static str {
"Five of Diamonds"
}
Related
I have a Vec of MyStruct (Vec<MyStruct>):
struct MyStruct {
attr1: i32,
...
}
let mut my_vec = Vec::new();
for _ in 1..100 {
my_vec.push(MyStruct::new());
}
And I need to set the attr1 to the same value val1 on all the instances on that Vec. What I have right now to do this is:
let new_attr1 = 42;
for my_str in my_vec.iter_mut() {
my_str.attr1 = new_attr1;
}
Is there a way to do this without a for loop that's more idiomatic?
Is there a way to do this without a for loop
Using for_each() maybe?
my_vec.iter_mut().for_each(|my_str| my_str.attr1 = new_attr1);
that's more idiomatic
No. In fact, it's the opposite:
It's generally more idiomatic to use a for loop
Two things to note about this code, however:
Prefer for my_str in &mut my_vec to for my_str in my_vec.iter_mut(). In fact, there's even a Clippy lint for that.
If you find yourself doing that a lot of times, you can define a macro for it:
macro_rules! set_all {
( $collection:ident . $attr:ident = $value:expr ) => {
for item in &mut $collection {
item.$attr = $value;
}
};
}
set_all!(my_vec.attr1 = new_attr1);
But I doubt this is better.
How can I access the methods of primitive types in Rust?
Concretely, I want to pass either one of the two slice methods split_first_mut and split_last_mut to a function operating on slices. I know you can wrap them in closures as a workaround, but I’d like to know if direct access is possible.
You can access the methods on primitives just like regular types:
u8::to_le();
str::from_utf8();
<[_]>::split_first_mut();
You can create a function that accepts a slice ops function:
fn do_thing<T>(f: impl Fn(&mut [u8])) -> Option<(&mut T, &mut [T])>) {
// ...
}
And pass in both split_first_mut and split_last_mut:
fn main() {
do_thing(<[_]>::split_first_mut);
do_thing(<[_]>::split_last_mut);
}
You have to refer to the method using fully-qualified syntax. In a nutshell: <T>::{method_name} where T is the type and {method_name} is the name of the method. For example, if you're modifying a [i32] then you'd to prefix the method name with <[i32]>:: like this:
fn apply_fn<T, U>(t: T, t_fn: fn(T) -> U) -> U {
t_fn(t)
}
fn main() {
let mut items: Vec<i32> = vec![1, 2, 3];
let slice: &mut [i32] = items.as_mut_slice();
let first_split = apply_fn(slice, <[i32]>::split_first_mut);
let slice: &mut [i32] = items.as_mut_slice();
let last_split = apply_fn(slice, <[i32]>::split_last_mut);
}
playground
I am writing a small program that randomly selects an entry from an enum. Sample code:
#[derive(Debug)]
enum SettlementSize {
VILLAGE,
TOWN,
CITY
}
impl Distribution<SettlementSize> for Standard {
fn sample<R: Rng + ?Sized>(&self, rng: &mut R) -> SettlementSize {
let res = rng.gen_range(0, 3);
match res {
0 => SettlementSize::VILLAGE,
1 => SettlementSize::TOWN,
2 => SettlementSize::CITY,
_ => panic!("Unknown value!")
}
}
}
fn get_settlement_size(mut rng: impl RngCore) -> SettlementSize {
let size: SettlementSize = rng.gen();
size
}
Now, of course I want to test it. That's why get_settlement_size takes the rng value.
#[test]
fn random_human_readable() {
let rng = StepRng::new(1, 1);
assert_eq!("Town", get_settlement_size(rng).human_readable());
}
Unfortunately, this doesn't work. When I added some printlns, the value returned from:
rng.gen_range(0, 3);
is always 0. I copied StepRng code into my test module to add println inside and I see next_u32 and next_u64 called. However, later the code disappears into UniformSampler and at that point it becomes too hard for me to follow. What am I doing wrong? Can I somehow retain the testability (which means being able to set fixed results for random in my mind)?
You're right,
it is easy to mock the primitive functions of the RngCore trait,
but the way they are used to avoid bias from low order bits and
bias from modulus calculations make it very tricky to mock the
more complicated functions in RngCore.
IMO the simplest way to approach this is to place a layer between your use of the Rng and the code you want to test.
So instead of this:
fn get_settlement_size(mut rng: impl RngCore) -> SettlementSize {
let size: SettlementSize = rng.gen();
size
}
you have
trait RngWrapper {
fn get_settlement_size(&mut self) -> SettlementSize;
}
fn get_settlement_size(rng: &mut impl RngWrapper) -> SettlementSize {
rng.get_settlement_size()
}
Now your "real" implementation looks like this
impl Distribution<SettlementSize> for Standard {
fn sample<R: Rng + ?Sized>(&self, rng: &mut R) -> SettlementSize {
let res = rng.gen_range(0..3);
match res {
0 => SettlementSize::VILLAGE,
1 => SettlementSize::TOWN,
2 => SettlementSize::CITY,
_ => panic!("Unknown value!"),
}
}
}
struct Random<'a, R: RngCore> {
rng: &'a mut R,
}
impl<'a, R> RngWrapper for Random<'a, R>
where
R: RngCore,
{
fn get_settlement_size(&mut self) -> SettlementSize {
self.rng.gen()
}
}
And your mock could look something like this:
struct AlwaysTown {}
impl RngWrapper for AlwaysTown {
fn get_settlement_size(&mut self) -> SettlementSize {
SettlementSize::TOWN
}
}
Now you can test anything that uses get_settlement_size(), but you've not addressed testing of Random<'_, ThreadRng>::get_settlement_size - However this is now an isolated issue and doesn't require the "being able to set fixed results for random" that you mention in your question - instead I'd do a statistical test - that each of the expected cases comes out roughly the expected number of times.
If you want this rigorous, then you need a bit of stats (which I'm not going to put here) - but you should be able to put together a rough test that will pass 99.99+% of the time.
A full example, except the statistical tests on RngCore, is on the playground.
I've been working to try to optimize a section of my code and I've hit an area where I think I could use some community wisdom. I'm essentially trying to merge two elements of a list without moving the elements in the list (via two removes and an insert), because as far as I can tell in Rust doing so to a vector costs O(n) time.
Take a glance at the code that captures the essence of my problem:
use std::cell::RefCell;
use std::rc::Rc;
use std::collections::BinaryHeap;
#[derive(PartialOrd, Ord, PartialEq, Eq)]
pub struct Num {
pub num: usize
}
impl Num {
pub fn new(num: usize) -> Num {
Num {
num
}
}
}
fn main() {
let mut a = vec![];
for i in 0..10 {
a.push(Rc::new(RefCell::new(Num::new(i))));
}
let mut b = BinaryHeap::with_capacity(a.len());
for i in 0..a.len() - 1 {
b.push((i, Rc::clone(&a[i]), Rc::clone(&a[i + 1])));
}
drop(a);
while !b.is_empty() {
let c = b.pop().unwrap();
let first = c.1;
let next = c.2;
println!("c: c.0: {}", c.0);
println!("c: first.num before: {}", RefCell::borrow(&first).num);
println!("c: next.num before: {}", RefCell::borrow(&next).num);
// Here I want to replace the two structs referenced in first and next
// with a single new struct that first and next both point to.
// e.g. first -> new_num <- next
println!("c: first.num after: {}", RefCell::borrow(&first).num);
println!("c: next.num after: {}", RefCell::borrow(&next).num);
assert_eq!(RefCell::borrow(&first).num, RefCell::borrow(&next).num);
}
}
I want to be able to take two elements within a list, merge them into one pseudo-element, where the two previous "elements" are actually just pointers to the same new element. However, I'm having trouble finding a way to do this without copying memory or structures around in the list.
My understanding of your requirement is that you need the Vec to be able to hold items that are either a value or a reference to another item, while keeping the structure similar to what you have presented.
We can model that by changing your item type to an enum, which can hold either a value or a reference to another item:
pub enum Num {
Raw(usize),
Ref(Rc<RefCell<Num>>),
}
And add methods to include abstractions for constructing the different variants and for accessing the underlying numeric value:
impl Num {
pub fn new(num: usize) -> Num {
Num::Raw(num)
}
pub fn new_ref(other: Rc<RefCell<Num>>) -> Num {
Num::Ref(other)
}
pub fn get_num(&self) -> usize {
match &self {
Num::Raw(n) => *n,
Num::Ref(r) => r.borrow().get_num()
}
}
}
If you create a new value like this:
let new_num = Rc::new(RefCell::new(Num::new(100)));
You can reference it in other nodes like this:
*first.borrow_mut() = Num::new_ref(Rc::clone(&new_num));
*next.borrow_mut() = Num::new_ref(Rc::clone(&new_num));
The full code then looks like this:
use std::cell::RefCell;
use std::rc::Rc;
use std::collections::BinaryHeap;
#[derive(PartialOrd, Ord, PartialEq, Eq)]
pub enum Num {
Raw(usize),
Ref(Rc<RefCell<Num>>),
}
impl Num {
pub fn new(num: usize) -> Num {
Num::Raw(num)
}
pub fn new_ref(other: Rc<RefCell<Num>>) -> Num {
Num::Ref(other)
}
pub fn get_num(&self) -> usize {
match &self {
Num::Raw(n) => *n,
Num::Ref(r) => r.borrow().get_num()
}
}
}
fn main() {
let mut a = vec![];
for i in 0..10 {
a.push(Rc::new(RefCell::new(Num::new(i))));
}
let mut b = BinaryHeap::with_capacity(a.len());
for i in 0..a.len() - 1 {
b.push((i, Rc::clone(&a[i]), Rc::clone(&a[i + 1])));
}
drop(a);
let new_num = Rc::new(RefCell::new(Num::new(100)));
while !b.is_empty() {
let c = b.pop().unwrap();
let first = c.1;
let next = c.2;
println!("c: c.0: {}", c.0);
println!("c: first.num before: {}", RefCell::borrow(&first).get_num());
println!("c: next.num before: {}", RefCell::borrow(&next).get_num());
*first.borrow_mut() = Num::new_ref(Rc::clone(&new_num))
*next.borrow_mut() = Num::new_ref(Rc::clone(&new_num))
println!("c: first.num after: {}", RefCell::borrow(&first).get_num());
println!("c: next.num after: {}", RefCell::borrow(&next).get_num());
assert_eq!(RefCell::borrow(&first).get_num(), RefCell::borrow(&next).get_num());
}
}
As for whether this will prove to be better performance than a different approach, it's hard to say. Your starting point seems quite complicated, and if you can simplify that and use a different underlying data structure, then you should try it and benchmark. I have often been surprised at the actual speed of O(n) operations on a Vec, even when the size is around 1000 items or more.
I have an enum with the following structure:
enum Expression {
Add(Add),
Mul(Mul),
Var(Var),
Coeff(Coeff)
}
where the 'members' of each variant are structs.
Now I want to compare if two enums have the same variant. So if I have
let a = Expression::Add({something});
let b = Expression::Add({somethingelse});
cmpvariant(a, b) should be true. I can imagine a simple double match code that goes through all the options for both enum instances. However, I am looking for a fancier solution, if it exists. If not, is there overhead for the double match? I imagine that internally I am just comparing two ints (ideally).
As of Rust 1.21.0, you can use std::mem::discriminant:
fn variant_eq(a: &Op, b: &Op) -> bool {
std::mem::discriminant(a) == std::mem::discriminant(b)
}
This is nice because it can be very generic:
fn variant_eq<T>(a: &T, b: &T) -> bool {
std::mem::discriminant(a) == std::mem::discriminant(b)
}
Before Rust 1.21.0, I'd match on the tuple of both arguments and ignore the contents of the tuple with _ or ..:
struct Add(u8);
struct Sub(u8);
enum Op {
Add(Add),
Sub(Sub),
}
fn variant_eq(a: &Op, b: &Op) -> bool {
match (a, b) {
(&Op::Add(..), &Op::Add(..)) => true,
(&Op::Sub(..), &Op::Sub(..)) => true,
_ => false,
}
}
fn main() {
let a = Op::Add(Add(42));
let b = Op::Add(Add(42));
let c = Op::Add(Add(21));
let d = Op::Sub(Sub(42));
println!("{}", variant_eq(&a, &b));
println!("{}", variant_eq(&a, &c));
println!("{}", variant_eq(&a, &d));
}
I took the liberty of renaming the function though, as the components of enums are called variants, and really you are testing to see if they are equal, not comparing them (which is usually used for ordering / sorting).
For performance, let's look at the LLVM IR in generated by Rust 1.60.0 in release mode (and marking variant_eq as #[inline(never)]). The Rust Playground can show you this:
; playground::variant_eq
; Function Attrs: mustprogress nofree noinline norecurse nosync nounwind nonlazybind readonly uwtable willreturn
define internal fastcc noundef zeroext i1 #_ZN10playground10variant_eq17hc64d59c7864eb861E(i8 %a.0.0.val, i8 %b.0.0.val) unnamed_addr #2 {
start:
%_8.not = icmp eq i8 %a.0.0.val, %b.0.0.val
ret i1 %_8.not
}
This code directly compares the variant discriminant.
If you wanted to have a macro to generate the function, something like this might be good start.
struct Add(u8);
struct Sub(u8);
macro_rules! foo {
(enum $name:ident {
$($vname:ident($inner:ty),)*
}) => {
enum $name {
$($vname($inner),)*
}
impl $name {
fn variant_eq(&self, b: &Self) -> bool {
match (self, b) {
$((&$name::$vname(..), &$name::$vname(..)) => true,)*
_ => false,
}
}
}
}
}
foo! {
enum Op {
Add(Add),
Sub(Sub),
}
}
fn main() {
let a = Op::Add(Add(42));
let b = Op::Add(Add(42));
let c = Op::Add(Add(21));
let d = Op::Sub(Sub(42));
println!("{}", Op::variant_eq(&a, &b));
println!("{}", Op::variant_eq(&a, &c));
println!("{}", Op::variant_eq(&a, &d));
}
The macro does have limitations though - all the variants need to have a single variant. Supporting unit variants, variants with more than one type, struct variants, visibility, etc are all real hard. Perhaps a procedural macro would make it a bit easier.