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.

Quote:

---

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.

Quote:

---

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.

I'd imagine a static variable allocated with new resides on the heap. Often static variables allocated with new are not deleted when their destructors are trivial and the programmer is assuming that the OS will cleanup the memory upon program completion. A reason delete might not be used is because it is difficult to control the order of construction (and therefore destruction) of static and global objects, so to avoiding deleting an object before another static or global object is done using it the delete is just skipped entirely.

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.

The problem still exists with an auto_ptr, though. If another static/global object needs to use that object when it is destructed, you cannot guarantee which will be destroyed first. The other object might be destroyed second and it won't be able to clean itself up properly.

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.

Quote:

---

Originally Posted by QuestionC

Everything allocated with new is stored on the heap.

---

unless new is overloaded ;)

I usually do something like this (not compiled) no need for new/delete

Code:

---

class Single
{
public:
static Single &instance()
{
  static Single single;

  return single;
}

private:

Single() {}
};

---

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.

Quote:

---

Originally Posted by CornedBee

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.

---

what with my implementation above? is that the phoenix thing?

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.