Are singletons considered good or bad for some config

Thank You

Consider a class

class database(){
private:
QString username;
QString password;
public:
database(){
// fetch data from text file and store in username and password
}
void getUsername();
void getPassword();

}

This class is used in 10 files where username and password is required.
Is singleton good to use here?
Why do I think singleton is good for here. It's just my opinion and it may be wrong😜😃

It has to open and close file 10 times to get the same data. So It will take more time and more resources. If I use singleton here, it will fetch those data only once and will use the same data for all classes.

Is this good way?
I have read more than 10 blogs on singleton on stackoverflow being called it as anti-pattern. It is mentioned always good to use other ways instead of singleton. If I should not use singleton What kind of pattern should I use to accomplish it

mpergand

Singletons are not so popular these days, fashions pass :)

Anyway, there's already a singleton in every Qt App :
QApplication

Thank You

@mpergand
What do you think in this scenario?
What should I use ?

mpergand

In a QApplication subclass add any method you need.
You can call this method anywhere:

class MyApplication : public QApplication
{
public:
static MyApplication*	instance() { return static_cast<MyApplication*>(QApplication::instance()); }

Database* database { return mDatabase; }

private:

Database* mDatabase;
}

Anywhere in your App
#include "MyApplication"

Database* database=MyApplication::instance()->database();

Thank You

@mpergand

I have some questions?

Which approach is better?
Why one over another?

mpergand

In your case, i don't see any good reason for not using a singleton.

This class is used in 10 files

The question is why do you need to access the database in so many places.

Thank You

@mpergand
I wanted to know about this.
I have been told to use only one connection in this forum multiple times. But also I wanted to know how we can do this problem

jsulm

@Thank-You https://doc.qt.io/qt-5/qsqldatabase.html already manages all your connections for you and you can get them at any place in your app using https://doc.qt.io/qt-5/qsqldatabase.html#database
There is absolutely no need to make your class a singleton.
Please take time to read https://doc.qt.io/qt-5/qsqldatabase.html - it shows how to do it properly and it also explains that you should not keep any QSqlDatabase instances as variables.

SimonSchroeder

There is one major problem with singletons: they get in the way of testing. It is easier when your function gets handed over an object instead of querying a singleton. In testing you can then easily exchange this object. You can still have a default parameter for this object which will pass in a default object. But, since you can have a default object plus other objects for tests, it is technically not a singleton anymore.

Another minor problem with singletons is the way they used to be implemented: as global variable (sometimes a global static class variable). Since processors got multiple cores and people started using threads more this introduces problems with the initialization order. In modern C++ you can use a static variable inside a function. The standard guarantees that it will only be initialized once even in multithreaded contexts. This is still relevant if you are planning on using a default object as default parameter in function calls just as I have explained in the first paragraph.

Still, in your concrete case you should have a look at @jsulm's answer.

mpergand

As an alternative, here a template class that manege a single instance of a object:

#define INITIALIZE_ONCE static bool _init_=false;    \
                        if(_init_) return; _init_=true;
  
template<class T>
class Single
{
    public:
        
        Single()
            {
            INITIALIZE_ONCE;
            sSingle=new T;
            qDebug()<<"sSingle="<<sSingle;
            }
        
    T* operator->()
            {
            return sSingle;
            }
    
    
    T* operator *()
            {
            return sSingle;
            }
    
   
    private:
        
        static T* sSingle;
};

template<class T>
T* Single<T>::sSingle=nullptr;


class Add
{
    public:
        
        int add()
            {
            i++;
            return i;
            }
        
    private:
        int i=0;
};

int main(int argc, char *argv[])
{    
    Single<Add> ss;
    Add* s=*ss;  // return the single instance
    qDebug()<<"sSingle="<<s;
    
    qDebug()<<Single<Add>()->add();
    qDebug()<<s->add();
    qDebug()<<ss->add();
    
    using A=Single<Add>;
    A a;
    qDebug()<<A()->add();
    qDebug()<<a->add();
    
  return 0;
}

Thank You

I respect every answer.
@jsulm had already answered how to handle this case here
https://forum.qt.io/topic/131013/headers-in-c and I asked it there too
I had implemented it in that project in main QApplication(). I guess and hope it was correct to connect database at the very beginning of program.

There he had mentioned about Singletons https://forum.qt.io/topic/131013/headers-in-c/5
So I wanted to know how it does and work and is it good or not.
But I wanted to know other methods only

A kinda silly question
How can we get the same way if there was no QSqlDatabase?
If it's too bad just ignore this one LOL

Thank you for your all answers

Christian Ehrlicher

@Thank-You said in Are singletons considered good or bad for some config:

How can we get the same way if there was no QSqlDatabase?

For example with Q_GLOBAL_STATIC - it's thread-safe (in contrast to @mpergand's solution)

kshegunov

@Thank-You said in Are singletons considered good or bad for some config:

So I wanted to know how it does and work and is it good or not.
But I wanted to know other methods only

I was intending not to take part in this one, but what can I say, I'm a masochist.

The Qt way™ is what Christian posted, however his comment is true only partially. The initialization of the global is thread-safe, the object behind is not. So if one assumes that the variable is going to be used from multiple threads then making the construction/destruction thread-safe is only half the job.

So I'll preach what I usually preach: don't use a singleton if you can avoid it. It's more trouble than it's worth, and ultimately it's worth very little to begin with.