I don't get why those are bad? - random-access strings - auto-increment operators
i += ++i;
what should be the result ? what is the result in C++ ? (undefined)
Things Rust shipped without
121–130 of 330 posts
Re: Things Rust shipped without
#122Earlier quoted context omitted.
union foo { int x; float y; }; union foo bad; bad.x = 100; printf("%f\n", bad.y); // undefined behavior (though usually works)
Which is actually a useful feature in some obscure optimizations, like this fast (approximate) square root: float half_r=r*0.5F; union { float y; int32_t i; }; y=r; i=0x5f375a86-(i>>1); y=y*(1.5F-(half_r*y*y)); return y;
If you want to reinterpret a float as an integer or vice versa, you can do that easily enough with Rust's unsafe functions:
fn approx_invsqrt(r : f32) -> f32
{
let y : f32 = unsafe {
let i : i32 = std::mem::transmute(r);
std::mem::transmute(0x5f375a86 - (i>>1))
};
return y*(1.5-(0.5*r*y*y));
}
fn main()
{
println!("approx_invsqrt(2.0) = {}", approx_invsqrt(2.0));
}
approx_invsqrt(2.0) = 0.70693Re: Things Rust shipped without
#123Earlier quoted context omitted.
The PoC did this: mod foo { #include "..." } Which is barely enough to say that Rust is hugely different than just #include-ing C files. I was talking more about linking objects incrementally and the consequences of that design, rather than singing the praises of headers (though I do rather like headers). I understand C from the compiler's perspective as well, having written my own linker and assembler from scratch m…
> Which is barely enough to say that Rust is hugely different than just #include-ing C files. Well, sure, if you want to get fancy enough you can make a module system out of #include. (Your code snippet isn't enough because it doesn't replicate privacy or imports.) But replicating something approximating Rust's module system with "#include plus other stuff" doesn't show that Rust's module system is "just #include". >…
> For example, consider math.h. If your program is using one function (say, sin) from math.h, you have to parse all the prototypes in math.h. (And if you have inlined functions or templates in the header files, you have to parse those too!)
Isn't this pretty much a solved problem with precompiled / pre tokenized headers? PTH are language / arch / compiler agnostic.
Re: Things Rust shipped without
#124Earlier quoted context omitted.
I think that the "expression-style" return looks good for short and "expression-like" function. Good fn inc(a: u32) -> u32 { a + 1 } fn foo(a: u32, b: u32) -> u32 { let x = a + b; a * x } Bad fn bar(...) -> bool { let mut success = false; let conn = getConnection(); ... if x > y { return false; } else if z It looks especially bad when the function has multiple early returns, and then the final return looks different.
Sheesh, it's such a little thing. "success" vs "return success;"
Doesn't work when you're not returning from a function (ie, EVERY OTHER PLACE a block can appear)
Re: Things Rust shipped without
#125What about things that Rust shipped without that should have been included?
An effects system. A safe stdlib - aborting on malloc failure is not safe.
Then you are using a different meaning for safe than what Rust usually does.
Abort occurs on oom, that's right and also on double panic (most frequently found if a destructor panics during unwinding).
Re: Things Rust shipped without
#126Re: Things Rust shipped without
#127Earlier quoted context omitted.
Tail call optimization https://mail.mozilla.org/pipermail/rust-dev/2013-April/00355... https://github.com/rust-lang/rust/issues/217 > I'm sorry to be saying all this, and it is with a heavy heart, but we tried and did not find a way to make the tradeoffs associated with them sum up to an argument for inclusion in rust. > -Graydon
Note that a lot has changed since April of 2013. Rust does have TCO, we just can't guarantee it. And, LLVM has come a long way, so we probably can support guaranteed TCO now, and have 'become' as a reserved keyword for this purpose. https://github.com/rust-lang/rfcs/issues/271 is a better link today.
That's really a good news! Thank you for pointing that out.
Re: Things Rust shipped without
#128Rust also shipped without reflection, which was available in the beginning. I was a bit disappointed as it was something I would have made use of for serialization.
Wouldn't it be better to create serialization functionality at compile-time?
In the Java space some libraries are moving to compile-time code generation instead of relying on reflection. It is a huge win, since a lot more can be checked beforehand. Dagger 2 is a good example how it can be beneficial. It provides dependency injection at compile-time, which will in turn check whether all dependencies are satisfied. I haven't seen this being done at compile-time before, but it is definitely a step up from reflection-based DI.
I'm not sure whether macros of Rust can provide such functionality, but the developers seem conservative when it comes to adding functionality. That seems like a good thing.
Re: Things Rust shipped without
#129Earlier quoted context omitted.
I don't know much about Rust and Rust library, so I have a question: what if I what to develop Windows only software in Rust, will I need to convert back and forth between UTF-16 and UTF-8 (or whatever Rust uses in other parts of the library)?
Yes. The Rust std library had to pick a string encoding, and it picked UTF-8 (which is really the best Unicode encoding). The String type is platform neutral and always UTF-8. However, it does provide an OsString type, which on windows is UTF-16. Maybe there is a library - and if not, one could be written - targeting Windows only, and implementing stronger UTF-16 string processing on the OsString type. EDIT: To be cl…
I believe Rust uses WTF-8 as an intermediate format for windowsy things (cheaper), but I'm not sure.
Re: Things Rust shipped without
#130Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
-- Antoine de Saint Exupéry