In the following text, I will distinguish between scoped objects, whose time of destruction is statically determined by their enclosing scope (functions, blocks, classes, expressions), and dynamic objects, whose exact time of destruction is generally not known until runtime. While the destruction semantics of class objects are determined by destructors, the destruction of a scalar … Read more
Probably the real reason that pure virtual destructors are allowed is that to prohibit them would mean adding another rule to the language and there’s no need for this rule since no ill-effects can come from allowing a pure virtual destructor. Nope, plain old virtual is enough. If you create an object with default implementations … Read more
UPDATE: This question was the subject of my blog in May of 2015. Thanks for the great question! See the blog for a long list of falsehoods that people commonly believe about finalization. When should I manually create a destructor? Almost never. Typically one only creates a destructor when your class is holding on to … Read more
Yes. You also need to implement the destructor: class A { public: virtual ~A() = 0; }; inline A::~A() { } should suffice. And since this got a down vote, I should clarify: If you derive anything from A and then try to delete or destroy it, A‘s destructor will eventually be called. Since it … Read more
Yes, it is possible to implement shared_ptr that way. Boost does and the C++11 standard also requires this behaviour. As an added flexibility shared_ptr manages more than just a reference counter. A so-called deleter is usually put into the same memory block that also contains the reference counters. But the fun part is that the … Read more
I’d recommend using Python’s with statement for managing resources that need to be cleaned up. The problem with using an explicit close() statement is that you have to worry about people forgetting to call it at all or forgetting to place it in a finally block to prevent a resource leak when an exception occurs. … Read more
For building containers you obviously want to use one of the standard containers (such as a std::vector). But this is a perfect example of the things you need to consider when your object contains RAW pointers. If your object has a RAW pointer then you need to remember the rule of 3 (now the rule … Read more
Because Java is a garbage collected language you cannot predict when (or even if) an object will be destroyed. Hence there is no direct equivalent of a destructor. There is an inherited method called finalize, but this is called entirely at the discretion of the garbage collector. So for classes that need to explicitly tidy … Read more
Temporary objects are destroyed at the end of the full expression they’re part of. A full expression is an expression that isn’t a sub-expression of some other expression. Usually this means it ends at the ; (or ) for if, while, switch etc.) denoting the end of the statement. In your example, it’s the end … Read more
Throwing an exception out of a destructor is dangerous. If another exception is already propagating the application will terminate. #include <iostream> class Bad { public: // Added the noexcept(false) so the code keeps its original meaning. // Post C++11 destructors are by default `noexcept(true)` and // this will (by default) call terminate if an exception … Read more