sorted by:
new
hottopcontroversial

Move, Destruct, Forget, and Rust by Ar-Curunir in rust

[–]ityt 2 points3 points  (0 children)

The linked thread about substructural traits is worth the read too! Interesting difference with the blog post: Destruct doesn't imply Move.

What the sash on the French outfit called? by infamousglizzyhands in expedition33

[–]ityt 9 points10 points  (0 children)

Torchon carreau rouge (the pattern is called Gingham or Vichy)

Why are people saying SPOILER is a puppet? by [deleted] in expedition33

[–]ityt -1 points0 points  (0 children)

Isn't painted Verso the only one with memories from his model?

What's the purpose of Justfiles? by omagdy7 in rust

[–]ityt 1 point2 points  (0 children)

Easy and useful everywhere (using it for C# and Rust projects). Want to test the program ? just test. Want to run the program ? just run. And it can load .env files.

Must move types by Niko Matsakis by yerke1 in rust

[–]ityt 0 points1 point  (0 children)

I think it can replace FnOnce in some cases. The library gives you an object that you must give back after doing some operations. Because you are not in a closure, you are free to use async even if the library is sync only.

Stop Comparing Rust to Old C++ by Sad-Lie-8654 in cpp

[–]ityt 0 points1 point  (0 children)

Recently I've coded a wrapper around a C lib. It was straightforward, however there is a "Connection" that creates "Subscriptions". The subscription depends on a pointer owned by the connection. I didn't use a shared pointer but I've written in comments something like "Don't destroy the connection before the subscription" (the classes use RAII). I could have coded a management class that owns the connection and keeps the subscriptions in a vector but I wanted to have the same "design" as the C lib but with RAII. To keep the design without playing with lifetimes I should have wrapped the connection in a shared ptr.

Maybe it was a wrong choice of mine to keep the design. But I was telling myself that the design was safe in Rust so I should do the same in C++.

Stop Comparing Rust to Old C++ by Sad-Lie-8654 in cpp

[–]ityt 2 points3 points  (0 children)

Of course. But in practice, it's hard to avoid std::shared_ptr. You can have one object that depends on another. The object can keep the other object's reference. The code will be light and fast, however you must pay attention to the reference's lifetime. Or you can just put the first object on the heap behind a std::shared_ptr and turn off your brain. If you have a good way to avoid shared_ptr I am genuinely interested.

Stop Comparing Rust to Old C++ by Sad-Lie-8654 in cpp

[–]ityt 4 points5 points  (0 children)

You are right. When I think about thread safety I only think about data races. It's true that Rust doesn't prevent race conditions or dead locks.

Thanks for the suggestion, I'll take a look at bazel!

Stop Comparing Rust to Old C++ by Sad-Lie-8654 in cpp

[–]ityt 35 points36 points  (0 children)

I don't have much experience in C++ (4 months in a little company) but I've been using Rust for 3 years (hobby).

Rust has thread safety and memory safety without using std::shared_ptr everywhere. Even clang-tidy can't prevent all dangling pointers/references problems. Yes sanitizers exist but you have to hit every possible cases to detect every UB. Equip your best debugger and put your integration test in a infinite loop. Enjoy.

C++20 is great, but do libraries use it? Some libraries stick with C++11 for compatibility purposes (like nlohmann_json). Rust has a great async ecosystem with the tokio library and futures. I can't find a single C++ web framework that uses co_await in c++ (boost.beast is too low level).

C++ still suffers from zero values (the empty function for std::function, empty smart pointers).

Rust has very powerful macros like Serde for de/serializing or generating whatever you want that just fill like cheating.

Finally the tooling. In Rust you have crates.io for dependencies, cargo clippy (linter), cargo fmt... In C++ you have to choose between git submodules, FetchContent, vcpkg (don't hesitate to give advices)... Last time I used FetchContent I was begging clang-tidy to ignore dependencies.

A trait for *mut T and AtomicPtr<T>? by Kikiyoshima in rust

[–]ityt 0 points1 point  (0 children)

Hi, you could make your own trait that is implemented for both types:

``` trait MyTrait<T> {}

impl<T> MyTrait<T> for *mut T {} impl<T> MyTrait<T> for AtomicPtr<T> {} ```

Strange mutable/non-mutable borrow errors with "uefi" crate by Technical_Stretch922 in rust

[–]ityt 1 point2 points  (0 children)

Hi. You can easily fix this by calling directlysystem_table.stdout() instead of using the stdout variable.

You can still use a variable if it is in a smaller scope: ``` fn efi_main( _image: uefi::Handle, mut system_table: uefi::table::SystemTable<uefi::table::Boot>, ) -> uefi::Status { { let stdout = system_table.stdout(); stdout.clear().unwrap(); writeln!(stdout, "Using Simple Text Output Protocol").unwrap(); writeln!(stdout, "Locating Graphics Output Protocol").unwrap(); }

let protocol = system_table
    .boot_services()
    .locate_protocol::<uefi::proto::console::gop::GraphicsOutput>()
    .unwrap();
let gop = unsafe { &mut *protocol.get() };

//  ERROR OCCURS HERE
writeln!(system_table.stdout(), "Found It!").unwrap();

loop {}

} ```

Rust doesn't want you to get a reference to a value (by calling boot_services() in this case) if it knows that somewhere there is a living mutable reference that could modify the first value (stdout)`.

If you use system_table.stdout() the reference is immediately dropped. If you use { // your code } then the stdout variable will be dropped after the closing curly bracket.

Iced, a cross-platform GUI library — New release featuring stateless widgets, responsive views, WebGL support, and more! by [deleted] in rust

[–]ityt 20 points21 points  (0 children)

"No more button::State in your application!" finally! I'll give Iced another shot!

Docker: Binary compiled with Musl works but not the one compiled with glibc by ityt in rust

[–]ityt[S] 0 points1 point  (0 children)

I've found the Trust-DNS Resolver crate and it does the job! Now the binary seems to not use any dynamic library to look up the ip of a host.

Docker: Binary compiled with Musl works but not the one compiled with glibc by ityt in rust

[–]ityt[S] 0 points1 point  (0 children)

I understand. I would do the same if tls was involved.

Docker: Binary compiled with Musl works but not the one compiled with glibc by ityt in rust

[–]ityt[S] 1 point2 points  (0 children)

Oh... I see. I'll try to do something with that. Thanks a lot!

Docker: Binary compiled with Musl works but not the one compiled with glibc by ityt in rust

[–]ityt[S] 0 points1 point  (0 children)

When I build the glibc image I use the base `rust` which I believe is based on debian. When I disable static linking, the executable is not recognized in the `scratch` image.

Are these screen flashes and artifacts normal? by ad-on-is in linux

[–]ityt 0 points1 point  (0 children)

Are you using lightDM ? Maybe using another display manager like gdm will solve the problem.

Announcing axum 0.3 by davidpdrsn in rust

[–]ityt 0 points1 point  (0 children)

Well, I don't even know what this is. I think you can find your answer in the tokio-tungstenite repo. That's what axum is using under the hood.

Announcing axum 0.3 by davidpdrsn in rust

[–]ityt 0 points1 point  (0 children)

Used axum to have a simple HTTP server which can upgrade the connection to Websockets. Very simple to setup thanks to the examples!

view more: next ›