I have to disagree to a certain extent. To describe it as by-the-book RAII may be technically incorrect…

Surely it’s a pretty important point since the article is titled “To RAII or Not to RAII?”, and the example didn’t “RA” when doing “I”.

It would be pointless to open the connection when the object is created, do a bunch of other processing unrelated to the Persistor instance, then finally save the state and close when the scope exits.

That’s RAII. You can disagree with it and say why. I think RAII advocates would have good responses, but that’s not my point. My point is clarity about the debate, and I’m arguing that what you can’t do is call something “RAII” when it’s definitely not.

Yes, RAII makes use of destructors to ensure that resources are cleaned up. That guranteed cleanup is what makes it great. But that only makes sense if you’re acquiring resources at some earlier time. If you acquire a resource, then something throws an exception, the dtor guarantees you cleanup the resource. Awesome sauce.

On the other hand, the original example given shows three things happening in the dtor itself: 1) acquire resource, 2) use it, 3) release the resource.
There is simply zero reason to put this in a dtor. No reason at all. Stick those 3 steps in a function somewhere. It’s not RAII. It’s not cleaning anything up. It doesn’t survive exceptions being thrown. This example is just using scope exit as a technique to call a function—the dtor—… but I can’t think of any reason why you would want to do that.

In fact, putting it in dtor makes it worse than just having those 3 steps in a function:
Acquiring resources can fail.
Actions using those resources can fail.

Doing the acquiring and actions in a destructor would mean there is no way to handle failure, or even know about it. The calling code would have to… keep going on the assumption that the call succeeded??

Or worse, if the code you call to acquire resources or do actions throws an exception, and you’re doing those things in a destructor, then you just crashed your program or put it into undefined territory.

So in conclusion: even if you don’t buy RAII’s goal of only acquiring resources in constructors (that’s what they mean by “Initialization”), you’ve got to represent the meaning of RAII properly when debating it. Saying that C++ lets you use the scope to run destructors is fine, but that’s not RAII. And specifically, acquiring new resources inside a destructor is like the opposite of RAII.

I have to disagree to a certain extent. To describe it as by-the-book RAII may be technically incorrect, but in the example given, it makes no sense to open the database connection in the constructor, when the only time it is used is in the destructor. A common best practice is to declare variables as close to their first use as possible. The Persistor class, conceptually speaking, isn’t meant to manage resources, but rather to save its state on destruction. In the first version of Persistor that is shown, the database connection is completely unneeded in every part of the class except the destructor, where all the work is done. It would be pointless to open the connection when the object is created, do a bunch of other processing unrelated to the Persistor instance, then finally save the state and close when the scope exits.

I think maybe you’re too hung up on the “resource acquisition” part of the terminology of RAII. The techniques that RAII, by definition, allow, are useful in other areas that have nothing to do with acquiring and releasing resources, and rightly get lumped into discussions of RAII. RAII has become more of a concept, rather than a hard rule that only applies to finite resources. I don’t think it’s wrong to conceptually express scope-exit-deferred operations in terms of RAII, because they are so closely related to the concept of releasing actual resources.

Unfortunately some analysis tools aren’t as smart as the compiler and will “warn” about such unused variables.

However, one way to ignore the problem completely is to consider the context class as a wrapping facade for the logger itself and log things through the context.

Hi Daryn, I see, thanks for taking the time to expose this insight. I’ve update the article in that sense and you’ve helped me better understand RAII. Thanks for providing your feedback.

People have adapted a technique developed for one use case, to a much wider range of use cases, and now the name doesn’t perfectly fit anymore because the new use cases aren’t necessarily about tidying up a finite resource.

Is that the crux of your argument? Do you want us to come up with a new name for the uses of the technique that are not about tidying up a finite resource?

I’m afraid I must agree. The same misunderstanding of RAII is evident in the Persistor example. You (addressing Jonathan Boccara, blog author) defined a Persistor class that is actually not RAII at all. As a result, your conclusion that “RAII is not adapted” (and that adding a save function would be better but “no longer use RAII”) is quite wrong.

In your design, the constructor does nothing, and the destructor does:
// open database connection
// save data_ in database
// close database connection

This is completely contrary to RAII. Every single definition of RAII agrees that resource acquisition should occur in the *constructor*. 100% never in a destructor.

In reality, the Persistor class is actually a great candidate for RAII design. The database connection is the resource. Acquire it in the constructor, use it as needed (save function), and close it in the destructor—guaranteed to run even if exception is thrown during save or other code in the calling scope.

class Persistor
{
public:
  explicit Persistor(Data const& data)
  {
    connection_ = ...; /* open database connection */
  }
  ~Persistor()
  {
    /* close database connection */
  }
  save(Data data)
  {
    /* save data in database */
  }
private:
  DatabaseConnection connection_;
};

I wouldn’t normally speak with such emphasis—don’t want to be mean—but since this article got linked from the Standard C++ blog, I felt more strongly about it. I’d suggest you update the article or even do the blog equivalent of a “retraction” at the top.

I’m not against doing things in the destructor but doing things in the destructor is not RAII. Not knowing what RAII is is dangerous.