Earlier quoted context omitted.
> it's easy to visually confirm everything is cleaned up. Yes and no. It's easy to not make a mistake in a function. It's basically impossible to not make this mistake in 1'000 functions. Especially as code evolves over time, being 99% perfect about this, or even 99.9% perfect, is just not good enough. Not nearly enough. And this reminds me of something Schneier said, that everyone can make a cryptographic algorithm…
> To prove a point, I spent an hour reading his opensource project > and found several resource leaks Sounds like some interesting case studies. Could you share some? > > if I find [… typo words(?) omitted … ] a leak in the code I > > usually refactor to make the correctness more obvious. I should rewrite this as - if I find a leak that I accidentally introduced, I will refactor in the process of correcting it, to ma…
There are non language ways to make things safer, sure. Take C++, one can do things other than RAII to avoid resource leaks, and it'll be a good pattern. But RAII is right there.
In C++ one can be disciplined about object ownership. But I find that in Rust "doing the right thing" is not optional.
Static and strong typing have similar virtues.
You can write fine software in assembly. Steve Gibson apparently does.
I'm not saying there are any silver bullets. I do appreciate that five minutes spent now being forced to think about object ownership, can save a six month project down the line refactoring to remove all shared_ptrs.
Not accidentally creating copies, because RVO has many conditionals on when it happens.
No silver bullets. But in my opinion C is always worse than at least a C++ subset deliberately chosen. Plain C is because you enjoy the journey, not because you'll get there faster or better.
In C++ you can refactor to RAII encapsulate, when a resource is leaked. In C you can't.