Trying to create a singleton and getting LNK2019 error



  • I'm trying to create a singleton function so I can access my MainWindow class as an instance from other classes, but in Windows I'm getting the following error:

    mainwindow.obj:-1: error: LNK2019: unresolved external symbol "private: static class MainWindow * MainWindow::w_instance" (?w_instance@MainWindow@@0PEAV1@EA) referenced in function "public: __cdecl MainWindow::MainWindow(class QWidget *)" (??0MainWindow@@QEAA@PEAVQWidget@@@Z)

    Here is the relevant code in my mainwindow.h:

    class MainWindow : public QMainWindow {
    	Q_OBJECT
    	public:
    		static MainWindow* instance();
    
    	private:
    		static MainWindow* w_instance;
    

    mainwindow.cpp

    MainWindow* MainWindow::instance() {
    	return w_instance;
    }
    

    What am I doing wrong?



  • It is C++ static variable issue. You did not initialise the static variable.
    Just add the following in MainWIndow.cpp

    MainWindow* MainWindow::w_instance = NULL;



  • @dheerendra
    I apologize if I sound dense, I'm not new to programming, but I'm relatively new to C++. Assuming you mean add it to the end of the main.cpp file, then MainWindow::instance() just returns NULL.


  • Qt Champions 2016

    Because you actually need an object the pointer is going to reference.

    MainWindow * MainWindow::instance()
    {
        if (!w_instance)
            w_instance = new MainWindow;
        return w_instance;
    }
    

    Here, however, I must strongly advise you not to use singletons in C++ (especially if you're not intimate with the language). They have many drawbacks, and in C++ the associated complications pile up really fast.



  • @eggbertx From which other object are you trying to access the window?

    If it's a QWidget child of the window (or child of child of child etc) then just use QWidget::window() to get access to the window object. You can also use qobject_cast on the returned value to cast safely to get to QMainWindow.

    Alternatively. Derive from QApplication and add a window accessor (setter/getter) there.



  • @kshegunov @matthew-kuiash
    I'm only trying to do this so I can access my main window's console (I'm making a Javascript IDE) from my util.cpp, nothing more, and the main window class has a console function for doing that. Ideally, I should be able to do

    MainWindow::instance().console("whatever");
    

    If a singleton is overkill, what would be a better way to do this?



  • @eggbertx One possibility is for your JS engine to emit signals when it wants to output some text e.g. emit output("whatever") then connect that signal to your main window by implementing a "console" as a slot.

    Another would be to derive your own application and implement "console" there which could call through (proxy) to you main window.

    If it were me I'd go for the first option using a queued connection as this would mean that my JS engine would not get held up by UI activity e.g. the adding of text to the console. YMMV



  • @matthew-kuiash This IDE is for a specific game engine, and while the developer does plan on standardizing its console output (especially its debugging module) as far as I know, he isn't going to focus on that yet. For the time being, I'm just going to use it to output information about the IDE for simple debugging.



  • add this line to the beginning of you MainWindow.cpp file. Just see the code snippet.

    #include "MainWindow.h"

    MainWindow* MainWindow::w_instance = NULL;

    MainWindow::MainWindow(QWidget *parent)
    : QMainWindow(parent)
    {
    }



  • @dheerendra
    Alright, that seems to be working but now I've run into a another problem. I can send the MainWindow::console string argument to the Qt Creator console via

    qDebug() << str;
    

    but regardless of how many times I call the function, it's only appending said argument to the console widget (QTextEdit) via

    ui->consoleWidget->appendPlainText(str.toString());
    

    the first time MainWindow::console("whatever") is called.



  • I did not understand issue clearly. Let me try to answer.

    1. when you put the qDebug() << str , are you seeing out put on the qtcreator console window ?
    2. Are you also appending the string to your textedit as well ?


  • @dheerendra

    1. yes, every time it's called
    2. yes, but it's only showing up the first time MainWindow::console("whatever") is called, regardless from where it's called.


  • Is bumping a thread for sake of trying to resolve the issue against the rules?


  • Qt Champions 2016

    @eggbertx said in Trying to create a singleton and getting LNK2019 error:

    Is bumping a thread for sake of trying to resolve the issue against the rules?

    No it's not, it's the preferred way.

    As for the issue. I wouldn't approach the issue that way. Singletons are pretty bad, and one should do well to avoid them if possible. Whenever one can't avoid using a singleton I always prefer the "pseudo-singleton" approach Qt employs, something along those lines:
    header

    class Singleton : public QObject
    {
    public:
        Singleton(QObject * parent = Q_NULLPTR);
    
        static Singleton * instance();
        
    private:
        static Singleton * _instance;
    };
    

    source

    Singleton * Singleton::_instance = Q_NULLPTR;
    
    Singleton::Singleton(QObject * parent)
        : QObject(parent)
    {
        Q_ASSERT(!_instance);
        _instance = this;
    }
    
    Singleton * Singleton::instance()
    {
        return _instance;
    }
    

    Then you create as a stack object in main() and use everywhere:

    int main(int argc, char ** argv)
    {
        QApplication app(argc, argv);
    
        Singleton singleton(&app);
        // Rest of code
    }
    

    This particular implementation does not suffer the usual problems with lazy-initialization singletons as memory leaking and thread-unsafe creation, but still does couple up the components. Anyway, a so-constructed global object one can use to connect with signals and slots to whatever UI control is needed at any point and does not impose a strange and unnecessary way of creating the main window. For example consider this:

    void Singleton::console(const QString & line) // Make a slot in the header
    {
        QTextStream stream(&allText); // allText is a member variable of type QString
        stream << line << endl;
    
        emit textChanged(allText);  // void textChanged(const QString &) is a notification signal
    }
    

    Then one could directly hook up this class' instance to the UI component:

    class MainWindow : public QMainWindow
    {
    	Q_OBJECT
    
    public:
        MainWindow()
            : QMainWindow(Q_NULLPTR)
        {
            ui.setupUi(this); // Or w/e is needed to set up the UI
    
            QObject::connect(Singleton::instance(), &Singleton::textChanged, ui.textEditWidget, &QTextEdit::setPlainText); // All that's really needed
        }
    };
    


  • @kshegunov The first example works perfectly. And thus far, I've only been using signals and slots for actions and button presses.


  • Qt Champions 2016

    I don't follow. What first example you mean?



  • @kshegunov Sorry, I meant the second code block, not the first. I'm not very familiar with assertions in general, so I've never heard of Q_ASSERT. Adding the code in the second block fixed the issue.


  • Qt Champions 2016

    @eggbertx said in Trying to create a singleton and getting LNK2019 error:

    Sorry, I meant the second code block, not the first. I'm not very familiar with assertions in general, so I've never heard of Q_ASSERT.

    The assertion here is only a tool to detect creating more than one instance of the class. Q_ASSERT is a Qt macro for regular debug assertions, it will be removed in release mode, so its purpose (as assertions in general) is to catch programmer errors while debugging. So if you use the class above like this:

    Singleton object1;
    Singleton object2; //< Here the assertion will be tripped and you can catch the error while debugging
    

    Adding the code in the second block fixed the issue.

    Do you mean the main window constructor where the connect is made? All code blocks are part of one single example, so I'd expect them to work together only. :)


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.