11–20 of 60 posts
Furthermore, I'd use with_capacity in both cases: Vec::with_capacity(list_of_lists.iter().map(|l| l.len()).sum())
Earlier quoted context omitted.
Ah thanks! I was going to ask in here to see if anyone knew because the explanation about overwriting the same vector seemed pretty off base. Never worked in Rust though so wondered if the iterator api had some weird optional notion of size that could be utilised throughout the chain.
> Never worked in Rust though so wondered if the iterator api had some weird optional notion of size that could be utilised throughout the chain. Fwiw, this does exist: [Iterator::size_hint] ( https://doc.rust-lang.org/std/iter/trait.Iterator.html#metho... )
Earlier quoted context omitted.
> Never worked in Rust though so wondered if the iterator api had some weird optional notion of size that could be utilised throughout the chain. Fwiw, this does exist: [Iterator::size_hint] ( https://doc.rust-lang.org/std/iter/trait.Iterator.html#metho... )
Yep that can be used for pre allocating the Vec like in the `with_capacity` example
Anyone have examples where fold leads to easier to read code than a for loop in Rust?
I have used fold for converting strings to a bitset in advent of code let string = "ewfsan"; let bitset = string.bytes().fold(0u32 |acc, ch| acc | 1 This is a idiom that I have used many times so this being more consice than a for loop is a plus Of course if you have never seen a syntax before it will make less sense that anything you have seen before
Anyone have examples where fold leads to easier to read code than a for loop in Rust?
I find it slightly difficult to read when the accumulator variable actually has multiple parts, like a complicated tuple. It's worse when part of the accumulator is a bool indicating whether it's finished; that's just a poor emulation of "break" in a for loop.
Earlier quoted context omitted.
> Never worked in Rust though so wondered if the iterator api had some weird optional notion of size that could be utilised throughout the chain. Fwiw, this does exist: [Iterator::size_hint] ( https://doc.rust-lang.org/std/iter/trait.Iterator.html#metho... )
It seems `map` should have less restrictive semantics (specifically ordering) than `for`, does that allow more optimization? I don't know much about Rust internals.
I think Ruby has some kind of feature that works like that but IIRC it looked less foot-gun more foot-bazooka. Does anyone know of any languages that solve that problem elegantly?
> Why is map so much faster? I am not sure. I suspect with the map() option the Rust compiler figures out it can avoid allocations altogether by simply writing over the original vector, while with the loop it can't. Or maybe it's using SIMD? I tried to look in the compiler explorer but I'm not competent enough yet to figure it out. Maybe someone else can explain! Yep, it's due to SIMD -- in the assembly for `using_ma…
using_map is faster because it's not allocating: it's re-using the input array. That is, it is operating on the input `v` value in place, equivalent to this:
pub fn using_map(mut v: Vec) -> Vec {
v.iter_mut().for_each(|c| *c += 1);
v
}