| > So you're saying if the code was higher quality it would have fewer bugs? I mean, well, yeah. That's not what I am saying, at all. You cannot do RAII in C. My point was that I believe that most of the bugs under discussion here would not have happened if a language that provides RAII capabilities had been used. > The problem with solutions like RAII is that it doubles down on programmer infallibility, from "good programmers don't write bugs" to "good programmers correctly use RAII."
> You haven't really solved the actual problem unless you have tooling available that won't let non-RAII be checked in at all. Does that exist? I don't understand what you are trying to say honestly. If you think that RAII requires the same level of attention and care as manual malloc()/free()/new/delete, then this makes me wonder if you even know what the point of RAII is. Given the same "programmer quality" (for the lack of a better term), the use of RAII will certainly reduce the occurrence of memory mismanagement bugs. For the tooling, you can use clang-tidy in C++ to enforce the use of smart pointers, make_unique, etc. E.g., see: https://www.bfilipek.com/2017/12/why-uniqueptr.html (I am sure there are other static checkers around that can spot the use of manual memory management functions, it's an easy thing to check for). So, please don't put words in my mouth. The claim was never that RAII gives you the mathematical certainty of the absence of certain classes of bugs. Rather the claim is that in practice the use of RAII would have prevented most of the bugs presented here. |
And sadly, most recent C++ surveys place the use of static anaylsis tooling at around 50%.