Singleton example in C++

gistfile1.c++

/*
 * Example of a singleton design pattern.
 * Copyright (C) 2011 Radek Pazdera

 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.

 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.

 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <http://www.gnu.org/licenses/>.
 */

#include <iostream>

class Singleton
{
    private:
        /* Here will be the instance stored. */
        static Singleton* instance;

        /* Private constructor to prevent instancing. */
        Singleton();

    public:
        /* Static access method. */
        static Singleton* getInstance();
};

/* Null, because instance will be initialized on demand. */
Singleton* Singleton::instance = 0;

Singleton* Singleton::getInstance()
{
    if (instance == 0)
    {
        instance = new Singleton();
    }

    return instance;
}

Singleton::Singleton()
{}

int main()
{
    //new Singleton(); // Won't work
    Singleton* s = Singleton::getInstance(); // Ok
    Singleton* r = Singleton::getInstance();

    /* The addresses will be the same. */
    std::cout << s << std::endl;
    std::cout << r << std::endl;
}

If you delete constructor with Singleton()=delete; even your internal methods won't be able to call constructor

Your implementation has a memory leak.

In what manner? Since their initialisation singletons are supposed to live as long as the application does, so you don't have to worry about that raw pointer as once the application execution ends, the application memory will be freed by the system anyway.

This is very bad example, first copy assignment and copy ctors should be deleted, also you fail to release memory.

This example is from 9 years ago. why you all people doing same critism again again like a parrot.When author write to this example , probably C++ 11 was not available.

Is this implementation thread-safe？

This example is from 9 years ago. why you all people doing same critism again again like a parrot.When author write to this example , probably C++ 11 was not available.

for C++03 you should declare copy constructor and operator and not implement them to work around

I see a bunch of people complain that memory is leaked. No it is not. The operating system will recover the memory (it essentially acts as a global variable).

Is this implementation thread-safe？

no i will make it

Is this implementation thread-safe？

no i will make it

This will make a new object. To prevent that you must delete copy constructor or make it private

Singleton a(*s);
std::cout << &a << std::endl;

//I implement this way

class Singleton 
{
private:

    Singleton() { }
    void operator delete(void*) {}; // such that its not deleted accidentally
public:

    Singleton(Singleton&) = delete; // Copy prohibited
    void operator=(const Singleton&) = delete; // Assignment prohibited
    Singleton& operator=(Singleton&&) = delete; // Move assignment
    static Singleton* getInstance();
    // This is a sample method
    std::chrono::system_clock::time_point getTime() const {
        auto now = std::chrono::system_clock::now();
        return now;
    };
};

Singleton* Singleton::getInstance() {
    static Singleton* pInstance_;
    return pInstance_;
}

@SwarajKetan Your singleton gets never created. You could either add a new to your getInstance implementation or avoid pointers completely like here:

Singleton& Singleton::getInstance() {
    static Singleton instance;
    return instance;
}

http://www.cplusplus.com/forum/general/43943/

https://stackoverflow.com/questions/55490024/stdcall-once-when-should-it-be-used
I think you should use std::call_once to prevent multi-thread problems