Question

If I were to create a node class, as shown below, and if it were used in a doubly-linked list, would it create an infinite loop upon deconstruction of the doubly linked list? Or would it terminate nicely?

class Node
{
    Node(  );

    ~Node(  )
    {
       delete mNext; //deallocs next node
    }

    Contact mContact;
    Node* mPrevious;
    Node* mNext;
}; 

Edit: If I modified the code to this would it work?

~Node(  )
{
   mPrevious = NULL;
   if (mNext->mPrevious != NULL)
   {
      delete mNext; //deallocs next node
   }
}

Edit 2: Or would this work best?

~Node(  )
{
   if (mPrevious != NULL)
   {
      mPrevious = NULL;
      delete mNext; //deallocs next node
   }
}

Answer 1

If considering the mNext pointer the nodes are forming a loop then then destruction of any of the nodes will indeed probably form an infinite recursive loop and it will terminate the program by blowing up the stack.

What it will probably happen is

1. The first “external” delete node; is issued.
2. When entering the node destructor nothing has been done yet as the code destructor is the “first” thing performed in the destruction process (the destruction process itself is quite involved and includes destructor code, class change, member destruction, base destruction in this order: see this answer for a more detailed explanation).
3. The first destructor instruction fill execute delete mNext; thus triggering the same process on next node in the loop.
4. Because the nodes are forming a loop this chain will reach node again “from the back” thus making the very first call a recursion that would never end.
5. Every call none the less will allocate stack space for the activation record, therefore after a while all the memory allowed to be used for the stack will be depleted and the OS will kill the process. The deletion call is not a “tail call” because after the destructor code completes the memory must be deallocated so this recursion cannot easily be optimized away… while delete mNext; is the last statement on the destructor still there are operations that must be performed after the delete operator completes.

Note however that in my experience a stack overflow unless you use special compiler options is not going to be checked and the program termination will therefore be quite “abnormal”. Note also that under Windows there is some horrible code that in some cases hides segfault errors if they happen on program termination, so it’s well possible that a windows program could just apparently terminate gracefully in this operaton is done after quitting the event loop.

Give that stack overlflow is not normally considered indeed any behavior is possible, including an apparent “infinite loop” (note that this infinite loop may be not the one of the recursive destructor but somewhere inside the runtime system getting crazy because of the stack overflow).

Why did I use the word probably? The reason is that the C++ standard says that multiple destruction of an object is Undefined Behavior. If you add this to the fact that there is no way in C++ to quit a destructor without completing the destruction you will understand that a compiler is in theory allowed to flag an object as “being destroyed” and to make a daemon fly out of your nosrils if you enter the destructor of the same object twice. Checking for this error is not mandatory however and compiler writers are often lazy (this is NOT an insult for a programmer) and therefore is unlikely that this check will be present (except may be if some special extra debugging option is enabled).

To sum it up: can it loop forever? yes. Can it crash? sure. Can it stop telling me that an object is being destroyed twice? of course. Can it just terminate the program nicely (i.e. witout setting any error code)? yes, that too.

Anything can happen. And Murphy says it will happen whatever is going to do the most damage to you… for example the program will terminate nicely every single time while you are developing it… and it will crash badly in you face during the demo day in front of a thousand prospective customers.

Just don’t do that 🙂