3 ms·

Is it important, when there is no other thread or process that could use any resource you're holding?

zokier 10y ago
Resource wouldn't necessary be something internal in the application, it could be also some external system or something like that. You might want to close TCP connections cleanly in destructors, or maybe more relevantly for embedded systems the resource might be some actual physical gadget that is activated/deactivated. Of course this is all hypotheticals and it could very well be argued that relying on destructors to do something actually critical would be a bad design.
- monocasa 10y ago
  > Of course this is all hypotheticals and it could very well be argued that relying on destructors to do something actually critical would be a bad design. Eh, I'd only argue that in the case of garbage collected languages. In RAII languages like Rust and C++, it's the preferred way.
  - twic 10y ago
    There's a classic interview question about RAII along the lines of "in what situation can a RAII resource be acquired, but not released?". The key answer is "if someone turns the power off". panic_fmt entering an infinite loop leads to pretty similar results as someone turning the power off. The stack will not be unwound, destructors will not be run, and bad designs will leave external resources in an inconsistent state.
    - monocasa 10y ago
      I mean, sure. loop {} ^--- That'll also cause destructors to not be run.
  - zokier 10y ago
    Rust notably has slightly weakened RAII semantics: https://github.com/rust-lang/rfcs/blob/master/text/1066-safe-mem-forget.md https://github.com/rust-lang/rfcs/blob/master/text/1066-safe... tldr is that Rust does not guarantee that dtors are run
    - steveklabnik 10y ago
      C++ doesn't either, see http://stackoverflow.com/questions/7054685/are-destructors-run-when-calling-exit http://stackoverflow.com/questions/7054685/are-destructors-r... for example.

Resource wouldn't necessary be something internal in the application, it could be also some external system or something like that. You might want to close TCP connections cleanly in destructors, or maybe more relevantly for embedded systems the resource might be some actual physical gadget that is activated/deactivated. Of course this is all hypotheticals and it could very well be argued that relying on destructors to do something actually critical would be a bad design.

monocasa 10y ago
> Of course this is all hypotheticals and it could very well be argued that relying on destructors to do something actually critical would be a bad design. Eh, I'd only argue that in the case of garbage collected languages. In RAII languages like Rust and C++, it's the preferred way.
- twic 10y ago
  There's a classic interview question about RAII along the lines of "in what situation can a RAII resource be acquired, but not released?". The key answer is "if someone turns the power off". panic_fmt entering an infinite loop leads to pretty similar results as someone turning the power off. The stack will not be unwound, destructors will not be run, and bad designs will leave external resources in an inconsistent state.
  - monocasa 10y ago
    I mean, sure. loop {} ^--- That'll also cause destructors to not be run.
- zokier 10y ago
  Rust notably has slightly weakened RAII semantics: https://github.com/rust-lang/rfcs/blob/master/text/1066-safe-mem-forget.md https://github.com/rust-lang/rfcs/blob/master/text/1066-safe... tldr is that Rust does not guarantee that dtors are run
  - steveklabnik 10y ago
    C++ doesn't either, see http://stackoverflow.com/questions/7054685/are-destructors-run-when-calling-exit http://stackoverflow.com/questions/7054685/are-destructors-r... for example.