> > And in both cases, the sizes would not be known until runtime, so they
> > could not be represented as [type * cnt]. In both cases, growing the
> > vector is of no importance.
>
> Oh, I think perhaps Niko overestimated what you were asking for. One
> can't create a _resizable_ @[], due to the managed ownership, but one
> with a fixed size that happens to only be learned at runtime should be
> quite possible, mutable or otherwise. I think this is just a missing
> function in our standard library for creating the mutable variant.
>
Thanks, it sounded like something that should be possible :)
Anyway, this brings me to yet another question/concern regarding mutable
managed vectors:
I was reading pcwaltons blog regarding the new borrow checker rules. It
mentions that for managed mutable boxes, attempting to mutate will go
through runtime checks to enforce these rules. It wasn't quite clear on
when these runtime checks actually do occur. Let's say I'm representing a
large matrix as @mut [float], and make a function to do some operating on
it:
fn fooOp(data : &mut [float]) {
for uint::range(0u, vec::len(data)) |idx| {
data[idx] = someOp(data[idx]);
}
}
Will the new borrow checker now cause such tight inner loops (that would be
a pretty common use case I'd assume) to have additional runtime overhead?
Sami
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
