Object instantiation within destructor of same class and garbage collection

Recently, while taking an introductory unit focused on Object Oriented programming, I was introduced to the Garbage Collector in C#, and that it's role is to "clean up" objects that are no longer being referenced. Then I was introduced to destructors, and how they're called just before the object is deleted.

Naturally, I got thinking, but I never remembered to ask the lecturer about it; what will happen if you create an instance of a class within the destructor of the same class?

C# example

class Person{
 ~Person(){

  Person p = new Person();
  Console.WriteLine("Person destroyed");

 }
}

class Program{
 static void Main(string[] args){
  Person p = new Person();
 }
}

I would like to approach this from a more theoretical point of view, so I'm reluctant (at this stage) to try it since I probably wouldn't understand anyway, but I have a few theories. Besides, I'm not at my regular computer right now ;)

• Person.~Person() is going to recurse, as each time the new Person is created, it's going to call its destructor and create a new Person ad infinitum, or until some kind of memory-related exception occurs. Subsequently, main will never terminate.
• The compiler will complain (adding this option to every scenario seems like a good idea anyway).
• Somehow, some kind of "destructor skipping" will occur. ie. object destruction wouldn't be called sequentially, so neither would the constructor.

Now for a similarly related question. If the Garbage Collector's role is to delete the objects that are no longer referenced/needed, how would a situation 开发者_如何学JAVAlike the one above be handled in an environment without a Garbage Collector - say, C++?

---

There's no real mystery here I think.

It won't 'recurse' as such - you're just chucking a new object on the managed heap which is immediately dereferenced; thus making it a candidate for garbage collection.

Eventually the garbage collector will come round again, triggering the operation again etc.

That's not recursion - more like a chain. But ultimately each Person will be removed from memory.

And, after a while the Garbage collector will send you an email complaining that you're not playing fair.

As for C++, well my guess is a stack overflow, since construction/destruction is happening there and then, and a very sulky computer afterwards.

If your next logical thought is 'shouldn't the runtime/language stop this from happening?' - no. The language or runtimes in question are not there to stop you doing something that would otherwise be considered ill-advised; it trusts you, the programmer, to make sure you're not doing that.

That said - in an application shutdown scenario (re your comment below) the .Net runtime is going to act out of self-interest and will ultimately stop processing these finalizers to enact a shutdown. Finalizers are for your benefit, not the runtime's.

---

A more interesting point to make is that an object can actually resurrect itself in the finalizer!

class Foo
{
    static public List<Foo> ZombieFoos = new List<Foo>;

    ~Foo()
    {
        ZombieFoos.Add(this);

        // Now there is a reference to this instance again (in the list)..
        // The GC will not reclaim this instance.. huzzah we have been resurrected!!
    }
}

Not even remotely recommended...

---

You could, in fact, cause system to be 99.9 time in GC. Just acquire sufficient amount of memory by every Person object for GC to trigger Heap 0 collection.