Header only c++ singleton pattern implementation
I have a problem with this because

template&lt;class Type&gt;
struct SingleTon
{
    static std::unique_ptr&lt;Type&gt; instance;


This is still a static storage duration object. This means its initialization can happen after a call to Type&amp; get(). So you have to solve this problem first.

So the instance variable needs to be wrapped in a function to make sure initialization of instance is guaranteed. If you are going to do that you may as well not dynamically create the object.

How about this:

template&lt;class Type&gt;
struct SingleTon
{
    private:
        static Type&amp; instance()
        {
            // Use static function scope variable to 
            // correctly define lifespan of object.
            static Type instance;
            return instance;
        }
    public:
        static Type&amp; get()
        {
            // Note the constructor of std::once_flag
            // is a constexpr and is thus done at compile time
            // thus it is immune to multithread construction
            // issues as nothing is done at runtime.
            static std::once_flag flag;

            // Make sure all threads apart from one wait
            // until the first call to instance has completed.
            // This guarantees that the object is fully constructed
            // by a single thread.
            std::call_once(flag, [] { instance(); });

            // Now all threads can go get the instance.
            // as it has been constructed.
            return instance();
        }
};


The Elephant in the room (Linker)

Now that we solved this issue. There is a larger elephant in the room to solve. (which is also true for the original code).

Since this is a template class with its whole definition in the header file there will be several versions of this function spread around the code (one in each compilation unit). It becomes the job of the linker to remove all but one copy. If you have a simple application that just uses object files this does not seem to be an issue.

BUT I have come across linkers that were unable to do this when the object were compiled into separate dynamically loaded libraries. Thus in effect your singleton becomes a singleton per runtime library that uses it. This is why you don't find Singelton libraries defined like this with a template class as the harness.