Question: I have very specific question about dynamically allocated static global object. In my project i have few object which I need to access from various places across the threads throughout the application lifetime. I want to create the at the application initialization and distroy when application exits. So I tried following,

Header File: MyObjectFactory.h

```
class MyObjectFactory{
   public:
      static MyObject* GetMyObject();
};

```

Source File: MyObjectFactory.cpp

```
static MyObject* gMyObject = 0;

MyObject* MyObjectFactory::GetMyObject(){
    if(gMyObject == 0)
    {
        gMyObject = new MyObject();
    }
    return gMyObject;
}

```

This code seems like working but i want to clear few things. 

1. Object will be created only once and then reference to object will be returned.
( I want this because MyObject encapsulate few system resource like text file)
2. MyObject gets destroyed when Application exits.
3. Where would be object created Heap (as I am using new ) or global memory (as I am using static)? Or am I violating any OOP principle?
4. Is it ok to call MyObjectFactory::GetMyObject() from multiple thread?
5. Is this a good way to achieve somewhat similar to Singleton?

Please let me know your input.

Thank You so much!

Answer: 
> 
> Object will be created only once and then reference to object will be returned. ( I want this because MyObject encapsulate few system resource like text file)
> 
> 
> 

* `MyObject*` is a pointer type, not a reference type. `gMyObject` is a variable of type pointer to `MyObject`.

> 
> MyObject gets destroyed when Application exits.
> 
> 
> 

* It does not, noone calls `delete` on your pointer so you have a leak.

> 
> Where would be object created Heap (as I am using new ) or global memory (as I am using static)? Or am I violating any OOP principle?
> 
> 
> 

* If you are using `new`, the object is created at the *'heap'*. The `static` only applies to the pointer to your object, not the object itself.

> 
> Is it ok to call MyObjectFactory::GetMyObject() from multiple thread?
> 
> 
> 

* It's not, you can cause multiple initializations if you have concurrent threads and the object wasn't constructed yet.

> 
> Is this a good way to achieve somewhat similar to Singleton?
> 
> 
> 

* It's not. Or maybe it is, but a singleton is usually a bad way to achieve something (and I only said *usually*).
> 
> Object will be created only once and then reference to object will be returned.
> 
> 
> 

If your program is single-threaded, yes (although in your example it returns a pointer not a reference). Otherwise there is a danger of two threads creating separate copies of the object; or in fact of anything else happening, since the behaviour is undefined in that case.

> 
> MyObject gets destroyed when Application exits.
> 
> 
> 

No, objects created with `new` will only be destroyed by `delete`, never automatically, so this object is leaked. Whether or not that is a problem depends on whether all the resources it uses are automatically reclaimed by the system.

> 
> Where would be object created Heap (as I am using new ) or global memory (as I am using static)? 
> 
> 
> 

The object is allocated from the free store (aka heap); the pointer to it is static.

> 
> Is it ok to call MyObjectFactory::GetMyObject() from multiple thread?
> 
> 
> 

Only if you can ensure that the object has already been created before either of them call it.

> 
> Is this a good way to achieve somewhat similar to Singleton?
> 
> 
> 

There's no good way to achieve that in C++. The best approach is to avoid globally accessible objects altogether; create it somewhere, and pass references to whatever needs it.

If you really want a global object, then there are a few options, each with their own deathtraps:

* A simple global object. Be careful of the Initialisation Order Fiasco if you have more than one of these, with dependencies between them.
* A function containing a static object, returning a reference to this. That is guaranteed to be initialised when you use it, and is thread-safe on a C++11 compliant implementation (and on many earlier implementations too). However, during program shutdown there is a danger that it might be destroyed before other static objects that are still trying to access it - you could perhaps avoid that by dynamically allocating and leaking the object, as in your approach. There may also be some runtime overhead from ensuring thread-safe construction.
* A lazily-allocated dynamic object (like you have), as long as you either make sure it's initialised before launching multiple threads, or add thread safety (which isn't entirely straightforward, and will add run-time overhead).