Revive object from destructor in C++?

Question

Disclaimer: I know this is bad design, I am simply asking the question out of curiosity in order to try to obtain deeper knowledge of how the destructor works in C++.

In C#, one can write: GC.KeepAlive(this) in the destructor of a class (see edit below), and that would mean that the object will still be alive in memory even after the destructor call is complete.

Does the design of C++ allow reviving an object from the destructor similar to the C# algorithm described above?

Edit: As pointed out by an answer below, GC.ReRegisterForFinalize() is more closely related to the question than GC.KeepAlive(this).

Answer 1

The short answer is: no. C++ does not employ garbage collection, like Java or C#. When an object is destroyed, it's destroyed immediately. Gone for good. Joined the choir invisible. Pining for the fjords, etc...

And to say this over a couple of times in different words so that there is no possible weasily reinterpretation...

The destructor is invoked as part of object destruction. Object destruction consists of invoking the destructor and deallocating the memory that was used for the object itself. It's a single process, not two separate processes. While the destructor is running, the object still exists, for the destructor to use, but it exists on borrowed time. It's a foregone conclusion that the object is going to be vaporized as soon as the destructor returns. Once a destructor is invoked, the object is going to be destroyed, and nothing is going to change its fate.

Understand this: the reason why a destructor is being invoked is because either: the object was originally allocated on the heap with "new", and it's now being "delete"d. "delete" means "delete", not "delete maybe". So the object's getting deleted. Or, if the object was allocated on the stack, the execution thread exited the scope, so all objects declared in the scope are getting destroyed. The destructor is, technically, getting invoked as a result of the object being destroyed. So, the object is being destroyed. The End.

Having said that, C++ allows you to implement a custom allocator for your classes. If you feel like it, you can write your own custom memory allocation and deallocation functions that implement whatever functionality you want. Though these are never used for stack allocated objects (i.e. local variables).

Answer 2

You are actually misrepresenting what GC.KeepAlive does in .NET. It is not to be used in a destructor of an object to keep that object from being destructed -- actually, GC.KeepAlive() is empty and has no implementation. See the .NET source code here.

It makes sure that the object passed as a parameter is not garbage collected before the call to GC.KeepAlive happens. The object passed to KeepAlive as a parameter can be garbage collected immediately after the call to GC.KeepAlive. Since KeepAlive has no actual implementation, this happens purely based on the fact that the compiler has to maintain a reference to the object to be passed as a parameter to KeepAlive. Any other function (that is not inlined by the compiler or runtime) taking the object as a parameter could be used instead as well.

Answer 3

Here's an idea:

C* gPhoenix= nullptr;

C::~C ()
{
gPhoenix= new C (*this);  // note: loses any further-derived class ("slice")
}

Now if the objects involved (bases or members) really do have destructors that do something, this runs into a problem if you delete gPhoenix; so you'll need more elaborate mechanisms depending on what it's really trying to accomplish. But you don't have any real goals, just curious exploration, so pointing this out should suffice.

When the body of the destructor is called, the object is still perfectly good. It appears perfectly vital and normal as you make normal member function calls from within the destructor.

The memory owning the object will be reclaimed, so you can't stick around in-place. And after leaving the body, other destruction takes place automatically and can't be interfered with. But, you can duplicate the object before that happens.

Answer 4

As has already been pointed out, GC.KeepAlive doesn't do that.

As long as .NET goes, it is possible to resurrect from the finalizer using GC.ReRegisterForFinalize, you can still get a reference to it if you have a WeakReference or GCHandle tracking ressurection, or just give this to something outside the class. Doing that will abort the destruction.

That is a old trick to detect garbage collection in .NET 2.0 no longer relevant, but still works (kinda, garbage collection can now be partial, and done in parallel with other threads).

Emphasis should be put on the fact that on .NET you are using a finalizer, which runs before destruction, and can prevent it. So, while it is technically correct that you can't recover an object after destruction - in any language - you can get close to the behaviour you describe in .NET, except using GC.ReRegisterForFinalize instead.

---

On C++, you have already been given the correct answer.

Answer 5

That's not possible in any language.

Your understanding is a bit off. GC.KeepAlive will mark the object as not collectible by the garbage collector. This will prevent the garbage collection strategy from destroying the object and it's useful if the object is used in unmanaged code where the garbage collector can't keep track of usage. This doesn't mean that the object is in memory after destruction.

Once an object begins the destruction the code will free resources (memory, file handlers, network connections). The order is usually from the deepest derived class back to the base class. If something in the middle were to prevent the destruction there's no guarantee that these resources could be re-acquired and the object would be in an inconsistent state.

What you want more likely is to have a std::shared_ptr that keeps track of copies and references and only destroys the object once nobody needs it anymore.

Answer 6

In case it helps, the destructor function and memory allocation are distinct.

The destructor is just a function. You can call it explicitly. If it does nothing destructive, then calling it again (e.g. when the object goes out of scope or is deleted) is not necessarily problematic, although it would be very strange; possibly there is a section dealing with this in the standard. See example below. For example, some STL containers explicitly call the destructor since they manage object lifetimes and memory allocation separately.

Typically the compiler will insert code to call the destructor when an auto variable goes out of scope, or a heap allocated object is destroyed with delete. This deallocation of memory cannot be tampered with inside the destructor.

You can take charge of memory allocation by providing additional implementations of the new operator, or using existing ones like placement new, but the general default behaviour is that the compiler will call your destructor, and that's a chance to tidy up. The fact that some memory will subsequently be cleared up is outside the control of the destructor.

#include <iostream>
#include <iomanip>

namespace test
{
  class GotNormalDestructor
  {
    public:
      ~GotNormalDestructor() { std::wcout << L"~GotNormalDestructor(). this=0x" << std::hex << this << L"\n"; }
  };

  class GotVirtualDestructor
  {
    public:
      virtual ~GotVirtualDestructor() { std::wcout << L"~GotVirtualDestructor(). this=0x" << std::hex << this << L"\n"; }
  };

  template <typename T>
  static void create_destruct_delete(wchar_t const name[])
  {
    std::wcout << L"create_destruct_delete<" << name << L">()\n";
    {
      T t;
      std::wcout << L"Destructing auto " << name << L" explicitly.\n";
      t.~T();
      std::wcout << L"Finished destructing " << name << L" explicitly.\n";
      std::wcout << name << L" going out of scope.\n";
    }
    std::wcout << L"Finished " << name << L" going out of scope.\n";
    std::wcout << L"\n";
  }

  template <typename T>
  static void new_destruct_delete(wchar_t const name[])
  {
    std::wcout << L"new_destruct_delete<" << name << L">()\n";
    T *t = new T;
    std::wcout << L"Destructing new " << name << L" explicitly.\n";
    t->~T();
    std::wcout << L"Finished destructing new " << name << L" explicitly.\n";
    std::wcout << L"Deleting " << name << L".\n";
    delete t;
    std::wcout << L"Finished deleting " << name << L".\n";
    std::wcout << L"\n";
  }

  static void test_destructor()
  {
    {
      std::wcout << L"\n===auto normal destructor variable===\n";
      GotNormalDestructor got_normal;
    }

    {
      std::wcout << L"\n===auto virtual destructor variable===\n";
      GotVirtualDestructor got_virtual;
    }

    {
      std::wcout << L"\n===new variables===\n";
      new_destruct_delete<GotNormalDestructor>(L"GotNormalDestructor");
      new_destruct_delete<GotVirtualDestructor>(L"GotVirtualDestructor"); 
    }

    {
      std::wcout << L"\n===auto variables===\n";
      create_destruct_delete<GotNormalDestructor>(L"GotNormalDestructor");
      create_destruct_delete<GotVirtualDestructor>(L"GotVirtualDestructor");
    }

    std::wcout << std::endl;
  }
}

int main(int argc, char *argv[])
{
  test::test_destructor();

  return 0;
}

Sample output

===auto normal destructor variable===
~GotNormalDestructor(). this=0x0x23fe1f

===auto virtual destructor variable===
~GotVirtualDestructor(). this=0x0x23fe10

===new variables===
new_destruct_delete<GotNormalDestructor>()
Destructing new GotNormalDestructor explicitly.
~GotNormalDestructor(). this=0x0x526700
Finished destructing new GotNormalDestructor explicitly.
Deleting GotNormalDestructor.
~GotNormalDestructor(). this=0x0x526700
Finished deleting GotNormalDestructor.

new_destruct_delete<GotVirtualDestructor>()
Destructing new GotVirtualDestructor explicitly.
~GotVirtualDestructor(). this=0x0x526700
Finished destructing new GotVirtualDestructor explicitly.
Deleting GotVirtualDestructor.
~GotVirtualDestructor(). this=0x0x526700
Finished deleting GotVirtualDestructor.


===auto variables===
create_destruct_delete<GotNormalDestructor>()
Destructing auto GotNormalDestructor explicitly.
~GotNormalDestructor(). this=0x0x23fdcf
Finished destructing GotNormalDestructor explicitly.
GotNormalDestructor going out of scope.
~GotNormalDestructor(). this=0x0x23fdcf
Finished GotNormalDestructor going out of scope.

create_destruct_delete<GotVirtualDestructor>()
Destructing auto GotVirtualDestructor explicitly.
~GotVirtualDestructor(). this=0x0x23fdc0
Finished destructing GotVirtualDestructor explicitly.
GotVirtualDestructor going out of scope.
~GotVirtualDestructor(). this=0x0x23fdc0
Finished GotVirtualDestructor going out of scope.