> Having written and read lots and lots of C++, RAII being "hidden" is hugely overblown by the diehard C crowd.
I work on low level projects which use both at the same time.
> If a given type cannot be safely cleaned up in a given context, then it probably also wasn't safe to get in that context in the first place.
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. There might also be multiple ways to get rid of the type. This was an "obvious" example, the ones that bite you are the non-obvious ones of course.
And yes, I have anticipated both the "but you still call functions in C" and the "functions may change" comment. True, but you call those functions explicitly, at a very explicit point (which you can also surround with other code), and anyone who works on a cleanup/destructor-like function can very easily figure out all call sites.
My point is precisely that you tend to run into these icky issues when deep in the bowels of a system, not when writing a smartphone app.
> And second it goes so so far in preventing resource leak bugs, which is also something kernels and low level code care a lot about.
Kernels do care about that, true. But if you exchange resource leak bugs for invalid state, which translates much more happily into security bugs, you are definitely worse off.
> 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.
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.
I work on low level projects which use both at the same time.
> If a given type cannot be safely cleaned up in a given context, then it probably also wasn't safe to get in that context in the first place.
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. There might also be multiple ways to get rid of the type. This was an "obvious" example, the ones that bite you are the non-obvious ones of course.
And yes, I have anticipated both the "but you still call functions in C" and the "functions may change" comment. True, but you call those functions explicitly, at a very explicit point (which you can also surround with other code), and anyone who works on a cleanup/destructor-like function can very easily figure out all call sites.
My point is precisely that you tend to run into these icky issues when deep in the bowels of a system, not when writing a smartphone app.
> And second it goes so so far in preventing resource leak bugs, which is also something kernels and low level code care a lot about.
Kernels do care about that, true. But if you exchange resource leak bugs for invalid state, which translates much more happily into security bugs, you are definitely worse off.