3 ms·

> Not true. As a quick example, the destructor might try to take some statistics, which might not be safe in an interrupt context, or when a thread is (internal

> Not true. As a quick example, the destructor might try to take some statistics, which might not be safe in an interrupt context, or when a thread is (internally) in an intermediate state. Which is a problem you also have in C. If someone is going and adding, say, lock duration statistics they aren't auditing all the C call sites just like they wouldn't be doing that with C++ destructors. Which you can search for, fwiw. You seem to be under an incorrect assumption that you can't find those usages. You can. > There might also be multiple ways to get rid of the type. This is not incompatible with RIAA. See for example unique_ptr's optional destructor. Of course, you're always free to just not use RIAA in those specific contexts.

anyfoo 4y ago
> Which is a problem you also have in C. Personal opinion will differ, but after reading and working on both C and RAII-heavy C++ low level code for many years (though I don't do the C++ one anymore), the low level C code just feels like fresh air when auditing.[1] It's all so explicit. For high level, as mentioned initially, I feel the opposite, as the boilerplate gets in the way. > Of course, you're always free to just not use RIAA in those specific contexts. That's my point, is it not? RAII in high level code, not in low level code. I did not claim they have to be in different code bases. And I am really not afraid of abstraction, my favorite language is Haskell. But that's so high level, and so far from the metal, that every function looks pure, and every value is lazy by default. [1] Personally, I think Rust would be my choice.