Does calling a destructor explicitly destroy an object completely?

Question

If I call a destructor explicitly ( myObject.~Object() ) does this assure me that the object will be appropriately destroyed (calling all child destructors) ?

Ok so

Answer 1

Please save yourself some real headaches and use the Boost Object Pool, which sounds like an existing implementation of your source/sink pattern. It will allocate large chunks of memory, slice them into the correct size for your object and return them to you (after calling the constructor). When you delete objects, they have their destructor called and are put into a linked list of objects for re-use. It will grow and shrink automatically and ensure that instances of your objects tend to be close together in memory.

If nothing else, it is a good example implementation of placement new and explicit use of constructors that you could study.

Answer 2

Why destroy it at all? Just write over the memory? Are you wanting logic to execute to gracefully handle releasing resources? I am going to state emphatically that this is an abuse of the language and not a good idea.

Answer 3

Yes. A destructor calls any member destructors in LIFO order, then base class destructors, and there is no way to prevent it from calling these destructors*. The object stack is guaranteed to unwind.

Initialization and finalization are separated from memory allocation and deallocation in C++ exactly so that when the special case arises, there is an unambiguous syntax in which the application-programmer can express his or her intent to the compiler.

Edit:

• I suppose that by invoking abort() or longjmp() one could, in fact, prevent the member and base class destructors from running.

Answer 4

STL containers do this. In fact, an STL allocator must provide a destroy method that calls an object's destructor (allcators also provide a deallocate method to deallocate the memory that used to hold an object). However, the advice from Stroustrup (The C++ Programming Language 10.4.11) is

Note that explicit calls of destructors ... should be avoided wherever possible. Occassionally, they are essential. ... A novice should think thrice before calling a destructor explicitly and also ask a more experienced colleague before doing so.

Answer 5

Yes. But holy smokes, are you sure about this? If so I would use placement new to construct your Widget. Using placement new and then explicitly calling the destructor is an acceptable, if unusual, idiom.

Edit: Consider allocating the memory yourself manually rather than using new to allocate the first object and then re-using its memory afterward. That allows you complete control over the memory; you could allocate big chunks at a time, for instance, rather than allocating a separate block of memory for each Widget. That'd be fair savings if memory really is such a scarce resource.

Also, and perhaps more importantly, you'd then be doing placement new "normally", rather than this hybrid regular new/placement new solution. I'm not saying it won't work, I'm just saying it's a rather, ah, creative solution to your memory problem.

Answer 6

Calling the destructor is fine. However, beware of the type you're calling it on. If that type doesn't have (didn't inherit) a virtual destructor, you might get unexpected behaviour.

Also, as mentioned, the destructor does not free any memory, but I guess that's the reason you want to call it manually in the first place.

Plus, unless I'm mistaken, calling the destructor manually is the only option you have if you used placement new to call the constructor.