Am 25.01.2013 01:37, schrieb Patrick Walton:
On 1/24/13 3:55 PM, Michael Neumann wrote:
Hi,
Again a couple of random question...
* Would it be possible to optimize this kind of enum (two cases, where
one case contains a borrowed pointer)
into a simple pointer, where None would be represented as the null
pointer?
enum Option<A> {
None,
Some(~A)
}
As the pointer to A can never be null it should be possible. This
probably wouldn't affect performance much,
but when storing it into an Array that would save a lot of space
(basically cut down space usage half).
Yes. This has been on the agenda for years. The reason why we don't
make any guarantees as to the memory layout for enums is precisely so
that we can implement optimizations like this.
Great to know that this will eventually be implemented.
* match() statements. I think the order in which the matches are
performed are important. But when I have
a very simple statement like this:
match io.read_char() as u8 {
0x0c => ...,
0x0d => ...,
0x0f .. 0x1a =>
...
}
will the compiler construct an efficient goto jump table or will it
construct sequential if statements instead?
ยด My question is if it makes sense to reorder more frequent cases to the
top or not.
LLVM will construct a jump table. I've verified this in my NES emulator.
Great. Hopefully it merges common statements as well. That is for
0x00 .. 0x0f => io::println("...")
it don't generate 15 separate io::println instructions. I assume it
generates a table which contains IP offsets.
Also I wonder why I get a "non-exhaustive patterns" error message for
this one:
match c as u8 {
0 .. 255 => 1
}
The exhaustiveness checker currently doesn't know about integer
ranges. This is probably a bug.
It's unituitive, so I think it's a bug :)
* Using str::as_bytes()
I cannot get str::as_bytes working. The example in the documention is
not working for several reasons (wrong syntax...)
I tried this:
fn write(buf: ~[u8]) {
io::println(fmt!("%?", buf));
}
fn main() {
let mystr = ~"Hello World";
do str::as_bytes(&mystr) |bytes| {
write(*bytes);
}
}
But get the compiler error:
t.rs:8:10: 8:16 error: moving out of dereference of immutable & pointer
t.rs:8 write(*bytes);
^~~~~~
I think you want `&[u8]`.
Of course! I feel little stupid now *g*.
* What exaclty is the semantic of "as"? Is it like a C-cast?
Imagine if I have
let b: u8 = 255;
let s: i8 = b as i8;
This gives -1 for s. But when I do "b as i32", it gives 255.
If I want to keep the sign I have to do "(b as i8) as i32".
It's supposed to be like a C cast. This seems like a bug to me.
Hm, for me it makes sense somehow.
I think that every cast from unsigned to signed (or vice versa)
will first extend the size to the requested size so that:
u8 as i32 equivalent to (u8 as u32) as i32
and this is clearly different to (u8 as i8) as i32, because
i8 as i32 will sign-extend, i.e. keep the upper bit.
Thanks for your answers,
Michael
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
