Re:Implementing Go's defer keyword in C++
by kentonv on Sunday October 22, 2017 @12:44PM
(#15527636)
> No one is suggesting this.
At least one person in this thread is, in fact, suggesting this: https://news.ycombinator.com/item?id=15524405
> They are saying that you use an RAII class such that it doesn't need tear down.
Yes, as I said in my original comment: "Of course, ideally state is encapsulated in classes with destructors and tear-down happens there, but writing a whole class can often be overkill for a one-off use case. If you don't have a defer macro, you're going to get lazy and introduce bugs."
I do know how destructors work, thanks.
Re:Implementing Go's defer keyword in C++
by quietbritishjim on Monday October 23, 2017 @06:24AM
(#15532060)
I guess I took your comment the wrong way. Sorry about that.
No one is suggesting this. They are saying that you use an RAII class such that it doesn't need tear down. In the example in the article, if std::ofstream calls close() in its destructor (which it does) then you don't need to DEFER a call to it. If you lock a mutex, use a RAII locker class so that you don't need to DEFER a call to unlock(). As someone once said of C++: "my favorite feature is the close brace", because it calls destructors for all objects on the stack, even during exception unwinding.
Of course, the article is just using RAII. But I disagree with the style; rather than re-writing a DEFER(myfile.close()) in every single function that uses a file object, you should make the file class have an appropriate destructor, or at least write a wrapper that does. That way you re-use that code rather than having to re-write it over and over.
> If you write C++ with exceptions, you need this.
You absolutely do not. You need to use the core language feature that it is using: deterministically-called destructors.