Thread: Static objects allocated with new

How are static objects managed when they are allocated with new? Where do these static object reside; in the heap or in the static memory?

I'm using a singleton as per the pattern described by the Gang of Four to implement a GameMap class, and I found it interesting the fact that the private object holding the sole class instance is allocated with new, but never explicitly deallocated with delete.

I confess I cannot see a way I could delete it explicitly. Certainly not in the class destructor. So it seems obvious (with my limited knowledge) that the language takes care of that for me.

But I'm still curious as to how this is done since C++ doesn't normally do this kind of resource management. And most particularly possible implications, if any, this might have on a singleton class that contains RAII-based data members.

Got a particular code example to go along with the question? As a guess, I'd say that the memory, appropriately sized (but uninitialized) for the given object, is reserved ahead of time by the compiler and resides alongside the rest of the static data. The new call is probably a call to placement new which initializes the object (calling any necessary constructor) within the memory location that has already been reserved at compilation time. There is no need to call delete on such an object because the memory was reserved ahead of time and does not come from the heap. Again, that's a guess, maybe someone else has a thought on this... or maybe be able to explain things better.

Originally Posted by hk_mp5kpdw

Got a particular code example to go along with the question?

Not at this moment, no. But I didn't deem it necessary, since I'm doing a straight, no nonsense, implementation of the Singleton Pattern (single-threaded).

I can come up with the actual code later today. But it won't add much, I reckon.

Originally Posted by hk_mp5kpdw

As a guess, I'd say that the memory, appropriately sized (but uninitialized) for the given object, is reserved ahead of time by the compiler and resides alongside the rest of the static data.

It can't be reserved since the size can only be really known at runtime. More so on this case where the singleton pattern is implementing a vector which dimensions are only known after reading from a database. Meanwhile there's no placement new. Just a straight call to new.

Everything allocated with new is stored on the heap.

And if the destructor of the allocated object needs to be called on program close, then just use a static std::auto_ptr instead of a static pointer.

You make sure your singletons don't depend on each other for destruction. The problem in your posed scenario is making interdependencies between singletons in the first place.

Static objects are by definition not allocated with new. If you assign the return value of new to a static pointer, then the static pointer lies in static memory, and the object allocated wherever new put it.

The GoF singleton is never deleted, its destructor never executed. The resources are reclaimed by the OS, hopefully. This is important to remember because:
1) You cannot use it on systems where the OS doesn't reclaim a process's resources. (Don't know if there are any left. I don't really think so.)
2) You cannot have destruction logic.

The Phoenix singleton attempts to overcome these problems.

It is interesting that you return a reference, instead of a pointer. I've seen that advise before even when applied to the GoF pattern (which allocates with new) because it encourages clients to not try and delete the object. I plan to do that from now on, regardless.

Meanwhile your implementation is the so called Meyers' one and addresses the problem of destroying the singleton. The phoenix singleton has something to do with singletons that reference other resources and need to ensure those resources are still there when destroyed. Naturally, it can be used for similar problems where destroying logic must be implemented, or so I think.

Tremendous help. Thanks everyone. For a moment there I suspected C++ was being sneaky about resource management and it did implement an automatic one even if only for static storage.