Can you guarantee destructor order when objects are declared on a stack?

Question

I have code that controls a mutex lock/unlock based on scope:

void PerformLogin()
{
    ScopeLock < Lock > LoginLock( &m_LoginLock );

    doLoginComma         


        

Answer 1

Yes, destructors are the reverse of constructors. Because destructors are used to delete the objects which are no longer required and constructor are use to create the objects.

Answer 2

Yes, it is. In any particular scope local objects are destroyed in the reverse order that they were constructed.

Answer 3

Yes, destructors are called in the reverse order of construction.

Answer 4

Adding on to Neil's answer.

Consider if the opposite was true, that is that you couldn't predict the order of destructors for stack declared variables. That would make it nearly impossible to use dependent value types on the stack. Consider

void Foo() {
  Type1 t1;
  Type2 t2(&t1);
  ...
}

If C++ did not guarantee destructor ordering, straight forward code like this would be incredibly unsafe because it would be possible for t1 to be destroyed before t2's destructor ran. Hence you could not guarantee t2's destructor ran with a valid t1 value.

Answer 5

The question was answered already, but I'd like to add that I typically have a habit of writing something like this:

void PerformLogin()
{
    ScopeLock < Lock > LoginLock( &m_LoginLock );
    doLoginCommand();

    {
        ScopeLock < SharedMemoryBase > MemoryLock( &m_SharedMemory );
        doStoreLogin();
        ...
    }
}

In my opinion, this makes the intent clearer (*). That might be relevant if your code really is relying on the specific order. I find that this makes it less likely that someone accidentally changes the order, and causes a hard-to-find bug. (Well, that is of course a non-issue, since we all have tests in place, don't we?)

I always write the redundant parentheses in something like  (a && b) || c  too, and I find this matter quite similar.

(*): Of course, you could use a comment as well.