rust

问题 I wrote a Rust library. I heard about the no_std feature and noticed that my library does not use anything from std that isn't offered by core and alloc. So in theory I could just add the #![no_std] attribute and change a few imports. But I wonder how this influences the users of my library. Of course, my hope is that by using #![no_std] , users in no_std environments can use my crate as well. That's good, of course. But: do users of my library have any disadvantage from my library being no

问题 I wrote a Rust library. I heard about the no_std feature and noticed that my library does not use anything from std that isn't offered by core and alloc. So in theory I could just add the #![no_std] attribute and change a few imports. But I wonder how this influences the users of my library. Of course, my hope is that by using #![no_std] , users in no_std environments can use my crate as well. That's good, of course. But: do users of my library have any disadvantage from my library being no

问题 It is clear from the reference manual that the memory layout of structs is unspecified (when the repr attribute is not used). This rule gives the compiler the possibility to pack structures tighter by reordering the fields. What about the memory layout of tuples and tuple structs? How is it (un)specified and why? 回答1: The memory layout of tuples and tuple structs is undefined, just like the layout of normal structs, with one exception: The exception to this is the unit tuple ( () ) which is

问题 I have functions that return an Option or a Result : fn get_my_result() -> Result<(), Box<Error>> { lots_of_things()?; Ok(()) // Could this be omitted? } fn get_my_option() -> Option<&'static str> { if some_condition { return Some("x"); } if another_condition { return Some("y"); } None // Could this be omitted as well? } Currently, neither Ok(()) or None are allowed to be omitted, as shown in the examples above. Is there a reason for that? Is it possible for this to be changed in the future?

问题 I am trying to understand the problems with duplicated code for & and &mut in getter-type functions. I'm trying to understand whether a particular solution to this problem using a cast inside an unsafe block would be safe. The following is an example of the problem. It is taken from the really nice tutorial Learning Rust With Entirely Too Many Linked Lists. type Link<T> = Option<Box<Node<T>>>; pub struct List<T> { head: Link<T>, } struct Node<T> { elem: T, next: Link<T>, } impl<T> List<T> { /

问题 Problem Description Hi! In our WebGL application, we are drawing many (even hundreds of thousands) shapes and we want to discover which shape is currently under the mouse. I'm looking for a way to do it in an efficient manner. Details The shapes are defined with Signed Distance Functions. Each shape is drawn by applying a predefined sdf fragment shader to a square polygon (2 triangles). Each shape is assigned with a unique ID ( uint ) on the Rust side (we're using WASM here). The idea is to

问题 Problem Description Hi! In our WebGL application, we are drawing many (even hundreds of thousands) shapes and we want to discover which shape is currently under the mouse. I'm looking for a way to do it in an efficient manner. Details The shapes are defined with Signed Distance Functions. Each shape is drawn by applying a predefined sdf fragment shader to a square polygon (2 triangles). Each shape is assigned with a unique ID ( uint ) on the Rust side (we're using WASM here). The idea is to

问题 Reading the docs, I noticed a sentence saying: "Rust doesn't have a C style for loop.". So, I wonder, how can I make a loop equivalent to for(i = 0; i < 10; i += 2) { } ? The ways I can think of are something like: for i in 0..10 { if i % 2 == 0 { //Do stuff } } Or even: let i = 0; loop { if i < 10 { //Do stuff i += 2; } else { break; } } But I'm not sure this is the best way, especially since it's really verbose. Is there a better way ? I'm guessing it would be with iterators , but I'm not

问题 I am writing a wrapper/FFI for a C library that requires a global initialization call in the main thread as well as one for destruction. Here is how I am currently handling it: struct App; impl App { fn init() -> Self { unsafe { ffi::InitializeMyCLib(); } App } } impl Drop for App { fn drop(&mut self) { unsafe { ffi::DestroyMyCLib(); } } } which can be used like: fn main() { let _init_ = App::init(); // ... } This works fine, but it feels like a hack, tying these calls to the lifetime of an

问题 I am writing a wrapper/FFI for a C library that requires a global initialization call in the main thread as well as one for destruction. Here is how I am currently handling it: struct App; impl App { fn init() -> Self { unsafe { ffi::InitializeMyCLib(); } App } } impl Drop for App { fn drop(&mut self) { unsafe { ffi::DestroyMyCLib(); } } } which can be used like: fn main() { let _init_ = App::init(); // ... } This works fine, but it feels like a hack, tying these calls to the lifetime of an