I'm baffled by this. Deterministic destruction (necessary and basically sufficient for RAII) was one of the best design decisions in C++, I think. RAII means you can't forget to clean up a resource. You don't have to type anything for it to get cleaned up at the right time, it just happens. It's basically what GC promised developers, except for all resource types, not just memory. Your code gets shorter and more correct.
I'm extremely curious to hear how this could ever be bad.
RAII isn't just about the destructor, though. It's about writing the constructor in such a way that you can always safely destroy the object. If you don't write the constructor right, RAII might become something you really hate, because it could blow up on you any time the destructor fires.
I meant that it's wonderful to use RAII classes that others have developed, rather than implement RAII classes for others to use. But now that you mention it:
>It's about writing the constructor in such a way that you can always safely destroy the object.
I agree, but I see this as a good thing, even though it makes the class slightly harder to implement than it might be if responsibility for getting the object into a state safe for destruction is dumped on (or even shared with) the calling code. The latter approach requires programmer discipline at every use -- but you will only implement the class once, and probably use it many times.
I'm baffled by this. Deterministic destruction (necessary and basically sufficient for RAII) was one of the best design decisions in C++, I think. RAII means you can't forget to clean up a resource. You don't have to type anything for it to get cleaned up at the right time, it just happens. It's basically what GC promised developers, except for all resource types, not just memory. Your code gets shorter and more correct.
I'm extremely curious to hear how this could ever be bad.