From the docs about __block __block variables live in storage that is shared between the lexical scope of the variable and all blocks and block copies declared or created within the variable’s lexical scope. Thus, the storage will survive the destruction of the stack frame if any copies of the blocks declared within the frame … Read more
If it suffices to preserve the group, you can set the setgid flag on the directories. See http://en.wikipedia.org/wiki/Setuid Setting the setgid permission on a directory (“chmod g+s”) causes new files and subdirectories created within it to inherit its group ID, rather than the primary group ID of the user who created the file (the owner … Read more
I’m not really much of a python guy, but I was able to whip this up: from os import stat from pwd import getpwuid def find_owner(filename): return getpwuid(stat(filename).st_uid).pw_name
std::vec::IntoIter is an owned version of every iterator, in a sense. use std::vec::IntoIter; struct Chunks { remaining: IntoIter<char>, } impl Chunks { fn new(s: String) -> Self { Chunks { remaining: s.chars().collect::<Vec<_>>().into_iter(), } } } Playground link Downside is additional allocation and a space overhead, but I am not aware of the iterator for your … Read more
The short version is that there’s a difference between the lifetimes that are inferred if the closure is written inline or stored as a variable. Write the closure inline and remove all the extraneous types: fn test(points: &[Point]) -> (&Point, f32) { let init = points.first().expect(“No initial”); fold(&points, (init, 0.), |(q, max_d), p| { let … Read more
Since BigInt implements Clone, you can use a std::borrow::Cow: use num::bigint::BigInt; // 0.2.0 use std::borrow::Cow; fn cal(a: BigInt, b: BigInt, floor: &BigInt) -> Cow<BigInt> { let c: BigInt = a – b; if c.ge(floor) { Cow::Owned(c) } else { Cow::Borrowed(floor) } } Later, you can use Cow::into_owned() to get a owned version of BigInt, or … Read more
You can create a function that accepts both &[String] and &[&str] using the AsRef trait: fn test<T: AsRef<str>>(inp: &[T]) { for x in inp { print!(“{} “, x.as_ref()) } println!(“”); } fn main() { let vref = vec![“Hello”, “world!”]; let vown = vec![“May the Force”.to_owned(), “be with you.”.to_owned()]; test(&vref); test(&vown); }
Modeling graph-like structures in Rust is not a simple problem. Here there are two valuable discussions from Nick Cameron and Niko Matsakis (two main Rust developers at Mozilla.) Graphs and arena allocation Modeling Graphs in Rust Using Vector Indices
Semantics Rust implements what is known as an Affine Type System: Affine types are a version of linear types imposing weaker constraints, corresponding to affine logic. An affine resource can only be used once, while a linear one must be used once. Types that are not Copy, and are thus moved, are Affine Types: you … Read more
You are completely right with both your reasoning and your observations. It definitely looks like things should be happening the way you describe it. However, the compiler applies some convenience magic here. Move semantics generally apply in Rust for all types that do not implement the Copy trait. Shared references are Copy, so they are … Read more