219: C++ RAII Sounds Complicated But Simplifies Your Code.

Resource allocation is initialization or RAII for short may be hard to pronounce but will help you write better and simpler code. Listen to this episode for an example that should help explain why RAII is an important technique to help us simplify our code so that we don’t have to manually clean up resources when we’re done. You can also read the full transcript below. Transcript There’s usually some tradeoff you need to consider when programming. Not everything has a single best way to do something and usually that means you have choices. Each choice will help you in some way and cause problems in another. One of the best known choices is between good, fast, and cheap. Pick any two. • If you want something made well that’ll last and you want it quick, then it won’t be cheap. • If you don’t want to sacrifice the quality and have a limited budget, then you’ll have to wait because you won’t get it soon. • Or if you want something as soon as possible and don’t want to spend a lot of money, then you should expect problems with the quality. There’s a tradeoff with RAII just like anything else. But the problems it helps you solve are well worth the extra code needed. And most of the time, you don’t have to write this extra code. You just need to be aware of the situation and know how to use RAII to your advantage. I’ve talked about this briefly in episodes 55 and 127. Listen to them for more information. In order to make full use of RAII, you’ll need a language like C++. I say like C++ even though C++ is the only language I know about that makes full use of RAII. But since there are hundreds of programming languages, it’s possible that you can use this technique in other places. Languages with garbage collection are not going to use RAII to its full extent. That’s because you really need a language that defines the lifetime of objects and especially the exact moment that their destructors will be called in order to make full use of RAII. Listen to episodes 17 through 22 for more information about object-oriented programming, constructors, and destructors. Imagine this scenario. You’re about to leave your house to go to work but want to fix something to eat first. So you crack open an egg into a frying pan and set it on the stove to cook. Then to save time, you start getting ready for work. The phone rings and you answer it. Just a robot sales call. But it distracts you just enough that you forget all about your egg, finish getting ready for work and leave to catch the 9am bus. You have a nagging feeling that you’re forgetting something but can’t quite remember what. You remember the egg only when you get home and open the door and smoke pours out. The whole house smells really bad. There was no fire but it’s hard to breath until you get all the windows open to vent out the smoke and smell. Your frying pan is warped and there’s nothing recognizable about the egg anymore. All of this happened because you forgot to turn off the stove. Maybe it was also caused by the phone call. But it comes down to this. Anytime we have to remember to do something important either in real life or in programming, we can expect mistakes like this to happen. What if there was a new type of stove that would shut itself off when it detected that nobody remembered it was on? Maybe it could detect if nobody was inside the house and turn off on its own? In order for this to work properly, the stove would need to turn itself off right away. It wouldn’t help much if you forgot to turn off the stove, the stove also recognized that nobody was home, but then it waited for a few extra hours before finally deciding that it should react. It needs to react right away in order to prevent burning. And this is where garbage collected languages struggle. There’s no fixed time when you can rely on your resources being cleaned up. It might happ