4 ms·

I used to do this sometimes with C++ when I realized that clearing out a vector with lots of objects was slow. Is Rust basically based on unique_ptr? One proble

I used to do this sometimes with C++ when I realized that clearing out a vector with lots of objects was slow. Is Rust basically based on unique_ptr? One problem with this approach was that you still had to wait for these threads when the application would shut down.

saagarjha 6y ago
Rust basically gives the compiler understanding of unique_ptr and prevents you from using it after you’ve moved it.
- Ididntdothis 6y ago
  Would you have to keep track of these threads in Rust? I have done a lot of desktop development where you have to be aware of what happens during shutdown. Seems a lot of server guys write their code under the assumption that it will never shut down.
  - firethief 6y ago
    The answer to this question is the same for any language without a heavy runtime. You can choose to join the worker thread, detach it, or kill it.
  - pornel 6y ago
    You would need to add `thread.join()` at the end of main, or have some RAII guard that does it for you. In practice that's probably optional, because the heap and all resources are usually torn down with the process anyway. Important things, like saving data or committing transactions, shouldn't be done in destructors.
- deleted 6y ago
  [deleted]
qcoh 6y ago
Out of curiosity, how did you do that in C++?
- Ididntdothis 6y ago
  It depends. Either iterate over the vector and delete the objects or just call clear(). Obviously you have to be sure that nobody else is accessing it at the same time.
zozbot234 6y ago
> One problem with this approach was that you still had to wait for these threads when the application would shut down. If you know that an object will live for the rest of the program and not need any finalization logic, Rust allows you to "leak" it and save that overhead on shutdown.
ordu 6y ago
You could have just one thread and to kill it at exit. Do not start new threads for each closure that drops object, send closures into one special thread instead.
masklinn 6y ago
> Is Rust basically based on unique_ptr? Rust is based on ownership and statically checked move semantics (by default though can be opted out). So each item has a single owner (which is why Rust deals very badly with graphs, and more generally any situation where ownership is unclear) and the compiler will prevent you from using a moved object (unlike C++). Separately it has a smart pointer which is the dual of unique_ptr (Box), with the guarantee noted above: let b = Box::new(1); drop(b); println!("{}", b); will not compile because the second line moves the box, after which it can't be used because it's been removed entirely from this scope.
- wnoise 6y ago
  > which is why Rust deals very badly with graphs, and more generally any situation where ownership is unclear To be fair, so do 90+% of programmers. Much of rust's benefit in safe code is training programmers to avoid code like that where possible, and spreading design patterns that avoid it.

saagarjha 6y ago

Rust basically gives the compiler understanding of unique_ptr and prevents you from using it after you’ve moved it.

Ididntdothis 6y ago
Would you have to keep track of these threads in Rust? I have done a lot of desktop development where you have to be aware of what happens during shutdown. Seems a lot of server guys write their code under the assumption that it will never shut down.
- firethief 6y ago
  The answer to this question is the same for any language without a heavy runtime. You can choose to join the worker thread, detach it, or kill it.
- pornel 6y ago
  You would need to add `thread.join()` at the end of main, or have some RAII guard that does it for you. In practice that's probably optional, because the heap and all resources are usually torn down with the process anyway. Important things, like saving data or committing transactions, shouldn't be done in destructors.
deleted 6y ago
[deleted]

qcoh 6y ago

Out of curiosity, how did you do that in C++?

Ididntdothis 6y ago
It depends. Either iterate over the vector and delete the objects or just call clear(). Obviously you have to be sure that nobody else is accessing it at the same time.

zozbot234 6y ago

> One problem with this approach was that you still had to wait for these threads when the application would shut down. If you know that an object will live for the rest of the program and not need any finalization logic, Rust allows you to "leak" it and save that overhead on shutdown.

ordu 6y ago

You could have just one thread and to kill it at exit. Do not start new threads for each closure that drops object, send closures into one special thread instead.

masklinn 6y ago

> Is Rust basically based on unique_ptr? Rust is based on ownership and statically checked move semantics (by default though can be opted out). So each item has a single owner (which is why Rust deals very badly with graphs, and more generally any situation where ownership is unclear) and the compiler will prevent you from using a moved object (unlike C++). Separately it has a smart pointer which is the dual of unique_ptr (Box), with the guarantee noted above: let b = Box::new(1); drop(b); println!("{}", b); will not compile because the second line moves the box, after which it can't be used because it's been removed entirely from this scope.

wnoise 6y ago
> which is why Rust deals very badly with graphs, and more generally any situation where ownership is unclear To be fair, so do 90+% of programmers. Much of rust's benefit in safe code is training programmers to avoid code like that where possible, and spreading design patterns that avoid it.