These are chat archives for rust-lang/rust

8th
Aug 2017
urugang
@urugang
Aug 08 2017 01:06
hi, all. i have a problem on 'cargo bench'. i have a stateful function 'func process(n: i32)', i want something like go's benchmark func benchmarkFib(i int, b *testing.B) { for n := 0; n < b.N; n++ { Fib(i) } }
but current bencher's implementation does not support it.
urugang
@urugang
Aug 08 2017 01:47
https://doc.rust-lang.org/1.12.1/book/benchmark-tests.html
here sugguest Make the code do "the same thing" on each iteration; do not accumulate or change state, but i think go's benchmark way is reasonable. there are some implement like iter_with_setup. https://github.com/japaric/criterion.rs/blob/master/benches/iter_with_setup.rs
demoneyes
@demoneyes
Aug 08 2017 08:22
Hello, can anyone recommend a web framework to use? I've had a look at rocket and iron but they are both tied to nightly builds of rust
im very risk averse :)
Denis Lisov
@tanriol
Aug 08 2017 08:26
iron does not require Nightly, IIRC... has it changed?
demoneyes
@demoneyes
Aug 08 2017 08:26
the website states that iron tracks rust nightly
Denis Lisov
@tanriol
Aug 08 2017 08:30
Well, at least all the examples compile and the tests do pass on stable.
demoneyes
@demoneyes
Aug 08 2017 08:32
ah that's great, maybe that will be a good option, will need to check if anything else will be affected, iron did seem quite mature
Denis Lisov
@tanriol
Aug 08 2017 08:43
I've been using Nickel for quite some time, but the project came to a halt. I'll have to look for a replacement, but I'll probably prefer something async-based.
demoneyes
@demoneyes
Aug 08 2017 08:55
will let you know what my experience with iron is
Michal 'vorner' Vaner
@vorner
Aug 08 2017 18:20
Hello. I looked at the mem::uninitialized and there's a huge warning about even reading that memory not being safe. I'm unclear about one thing, though. Is moving the variable considered reading? In other words, will this code be UB?
let x: String = mem::uninitialized();
let y = x; // Can this explode?
mem::forget(y); // Make sure drop is not called
red75prime
@red75prime
Aug 08 2017 19:07
@vorner, In this case it's probably not UB. Move is just a bitcopy and shouldn't be affected by semantics of the type. Unless the type is f32 or f64 and uninitialized bits happen to be representation of signaling NaN or something like that.
Anyway, why do you need it? It is clearly no op and semantically equivalent to mem::forget::<String>(unsafe{mem::uninitialized()}).
Michal 'vorner' Vaner
@vorner
Aug 08 2017 19:14
I don't need this, exactly, this is a minimized example. I've read about an interesting data structure and I'm trying to implement it. However, that data structure is based on an array that has „holes“. I could use Option there, but then it would waste space due to alignment issues, so I want to have a bit array with liveness of the values and an array of the values.
red75prime
@red75prime
Aug 08 2017 19:21
Well, you can't move out from an array, so your minimized example doesn't apply.
Michal 'vorner' Vaner
@vorner
Aug 08 2017 19:23
Vec has .drain(..). That hands me each value in turn and it internally does moves on passing through the iterator.next.
red75prime
@red75prime
Aug 08 2017 19:23
ah, vector then.
Michal 'vorner' Vaner
@vorner
Aug 08 2017 19:24
But I've moved to some other methods already. What I had in the drop wouldn't be safe during panics from drop.
red75prime
@red75prime
Aug 08 2017 19:24
If the type implements Drop, then you'll have UB.
Michal 'vorner' Vaner
@vorner
Aug 08 2017 19:26
I've this now, which I think should be safe (provided the marks about active and dead positions are accurate):
          for (i, active) in self.active.iter().enumerate() {     
              if active {
                  unsafe { ptr::drop_in_place(self.data.offset(i as isize)) };
              }       
          }
red75prime
@red75prime
Aug 08 2017 19:30
unsafe{ self.data.set_len(0); } before this code should prevent drop on uninitialized values in case of panic.
If I remember it right, Drain does it.
Michal 'vorner' Vaner
@vorner
Aug 08 2017 19:31
Currently data is a raw pointer.
red75prime
@red75prime
Aug 08 2017 19:31
then it's ok
Watch out for zero-sized types though
Michal 'vorner' Vaner
@vorner
Aug 08 2017 19:35
Yes, I have them in mind. Thanks for pointing them out, though.
But it seems I'll write the first version with Vec<Option<T>> anyway, to get the algorithm right. Rust is showing me I haven't thought the whole thing through properly again.