Trying to create a singleton and getting LNK2019 error

matthew.kuiash

@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.

eggbertx

@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?

matthew.kuiash

@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

eggbertx

@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.

dheerendra

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)
{
}

eggbertx

@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.

dheerendra

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

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

eggbertx

@dheerendra

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

eggbertx

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

kshegunov

@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
    }
};

eggbertx

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

kshegunov

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

eggbertx

@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.

kshegunov

@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. :)