Question

People always talk about how objects created without the new keyword are destroyed when they go out of scope, but when I think about this, it seems like that’s wrong. Perhaps the destructor is called when the variable goes out of scope, but how do we know that it is no longer taking up space in the stack? For example, consider the following:

void DoSomething()
{
  {
    My_Object obj;
    obj.DoSomethingElse();
  }
  AnotherFuncCall();
}

Is it guaranteed that obj will not be saved on the stack when AnotherFuncCall is executed? Because people are always saying it, there must be some truth to what they say, so I assume that the destructor must be called when obj goes out of scope, before AnotherFuncCall. Is that a fair assumption?

Answer 1

You are confusing two different concepts.

Yes, your object’s destructor will be called when it leaves its enclosing scope. This is guaranteed by the standard.

No, there is no guarantee that an implementation of the language uses a stack to implement automatic storage (i.e., what you refer to as “stack allocated objects”.)

Since most compilers use a fixed size stack I’m not even sure what your question is. It is typically implemented as a fixed size memory region where a pointer move is all that is required to “clean up” the stack as that memory will be used again soon enough.

So, since the memory region used to implement a stack is fixed in size there is no need to set the memory your object took to 0 or something else. It can live there until it is needed again, no harm done.