views:

615

answers:

5

Assume I have a function like this:

MyClass &MyFunction(void)
{
  static MyClass *ptr = 0;
  if (ptr == 0)
    ptr = new MyClass;
  return MyClass;
}

The question is at program exit time, will the ptr variable ever become invalid (i.e. the contents of that ptr are cleaned up by the exiting process)? I realize that this function leaks, but it is only an example for simplicity.

The same question also applies to other primitives besides pointers as well. How about if I have a static integer, does the value of that integer always persist throughout exit or is variable due to static destruction order issues?

EDIT:

Just to clarify, I want to know what actually happens to the contents of the static pointer (or any other primitive type like an int or a float) and not to the memory it is pointing to. For instance, imagine that the ptr points to some memory address which I want to check in the destructor of some other static class. Can I rely on the fact that the contents of the ptr won't be changed (i.e. that the pointer value won't be cleaned up during the static destruction process)?

Thanks, Joe

+4  A: 

In modern operating systems, all of an application's memory is allocated on a "heap" specific to that application. When the application exits, all of the memory in that heap will be freed.

So, the memory will be deallocated, but: the destructor for MyClass will never be called. This can be an issue if the destructor is responsible for releasing any non-memory resources (file system locks are a common example).

e.James
+6  A: 

When you process exits the all memory pages allocated to it will be freed by the OS (modulo shared memory pages that someone else may be using).

However, as others point out the destructor for MyClass is never called. Nor is the value pointed to by ptr ever changed. If you have a static int with the value 123 then its value will stay 123 through to the very end of the process' lifetime.

Rob Walker
Your comment about the value of the static int is what I was getting at as opposed to the fate of the memory. Do you know of any references which detail the guarantee of the value through the end?
Joe Corkery
I can't quote a reference to show this, but the OS has no need to clear the memory when the page is being freed, and for performance reason will avoid doing anything that is unnecessary.
Rob Walker
+3  A: 

To answer your updated question, I would say yes: you can rely on the value of that static pointer remaining throughout the static destruction process. The memory it points to may have been freed, but the value of the pointer itself should remain unchanged, unless the destructor of another static class makes a change to it.

e.James
+1  A: 

The short answer is "no": your pointer will not "become invalid" at program exit time. I.e. the pointer value will not automatically be reset to null, and destructor of the MyClass object to which it points will not automatically be called.

This is because a pointer is a "primitive type", i.e. not an object.

If you have a non-local (i.e. global or static) variable which is an object, then the rules are different: the destructor of the object will be called when the program terminates by calling exit() or by returning from the main function. It will not be called if the program terminates by calling abort().

Cayle Spandon
+3  A: 

To answer your question:

'imagine that the ptr points to some memory address which I want to check in the destructor of some other static class'

The answer is yes.
You can see the value of the pointer (the address).
You can look at the content if you have not called delete on the pointer.

Static function variables behave in the same way as static class variables and global variables (aka non local static), in that there destructors will be called in reverse order of creation. Integers, floats and pointers (POD) do not have destructors so nothing happens to them until the processes is removed.

POD objects: Data can safely by referenced from the destructor of other objects (even global s).

Other static objects (i.e. those with destructors): In the general case, it is not safe to accesses these objects after main() has exited because the order of destruction is not know (it is the reverse of the order of creation, but the order of creation is complex see: Construction Order ). It can be done but you have to take explicit precautions to make sure the object is still alive.

Note: non local static:

The memory will always be there, the object will just not be valid after a destructor is called (note POD does not have a destructor).

Note: Stack:

Only valid until the scope in which they are declared is left.
After the stack is popped the memory page that it is on could potentially be dropped resulting in SEG faults if you attempt to access it.

Note: Heap:

Valid until you call delete on the pointer that allocated it.
Once a pointer is delete the value is potentially random as it may be re-used. Potentially the page the memory was on can also be dropped. Any access to a dropped page would result in a SEG fault.

Martin York