Checking if running as command-line (QCoreApplication) or GUI

Perdrix

Is it correct to write:

if (qApp)
{
     // Do gui stuff
}
else
{
    // Do command line stuff
}

Thanks, David

JonB

@Perdrix
I imagine that is a reasonable test if you want to do a Qt call, as in: "is there a QApplication object?"

A global pointer referring to the unique application object. It is equivalent to QCoreApplication::instance(), but cast as a QApplication pointer, so only valid when the unique application object is a QApplication.

However, are you intending to use single-source with two separate compilations/links, one for GUI and one for console? Because if you are thinking you can do just one compilation/link and decide at runtime whether to run as GUI or command line you are going to stall. Under Windows at least --- which ISTR you use --- an executable is linked as either "windows" (GUI) or "console" (command-line) and you are stuck with that at runtime.

Perdrix

@JonB I build a GUI application which instantiates a QApplication in its main(), and a completely different piece of code is used for the command line application which creates a QCoreApplication.

So I think that qApp will work in that case?

JonB

@Perdrix
It may depend on platform or what you mean by command line. Have you just tested linking your command line program with a piece of code which goes if (qApp) and verified the final executable is still a command-line/console application?

SGaist

@Perdrix said in Checking if running as command-line (QCoreApplication) or GUI:

@JonB I build a GUI application which instantiates a QApplication in its main(), and a completely different piece of code is used for the command line application which creates a QCoreApplication.

So I think that qApp will work in that case?

Hi,

Something is not clear: are you starting both the CLI and the GUI from the same main function ?

Perdrix

They are completely independent executables each with their own main()

Christian Ehrlicher

As you can see here: https://doc.qt.io/qt-6/qapplication.html#qApp - qApp is not valid (undefined) when no QApplication instance exixst. When you simply look at the definition you will see what is happening:

#define qApp (static_cast<QApplication *>(QCoreApplication::instance()))

So no, it will not work and you will have to do it by yourself by calling dynamic_cast<> on the QCoreApplication::instance()

Perdrix

@Christian-Ehrlicher Well that's quite a surprise - from the documentation I had expected the macro to use a dynamic_cast<>

Christian Ehrlicher

@Perdrix said in Checking if running as command-line (QCoreApplication) or GUI:

 from the documentation I had expected the macro to use a dynamic_cast<>

Why? It's clearly stated:

"so only valid when the unique application object is a QApplication."

Perdrix

Which clearly said to me that it would be null if the application object is just a QCoreApplication...

So the docs really could be clearer (state that is it using a static_cast<>), or change the code to use a dynamic_cast<>!

Christian Ehrlicher

@Perdrix said in Checking if running as command-line (QCoreApplication) or GUI:

Which clearly said to me that it would be null if the application object is just a QCoreApplication...

undefined and a nullptr are two completely different things in c++ - the docs are very clear here.
https://en.cppreference.com/cpp/language/ub

Perdrix

The docs say nothing about undefined.

Christian Ehrlicher

"only valid" = undefined if the precondition is not met.

/edit:
valid pointer - a pointer to an object which is not yet deleted and has the correct class
invalid / not valid pointer - a pointer to an object which was already deleted or has an incorrect class
nullptr - a pointer to null

Perdrix

I still think the wording is open to my interpretation, however I have now defined my own convenience macro:

//
// Define a convenience macro for checking if we're using a Qt GUI or command line application
// 
#define qtGUI (dynamic_cast<QApplication *>(QCoreApplication::instance()))

Perdrix

After further experiments this seems to be a non-starter. I wanted to use a message box for GUI and cout for command line, but of course the command line code isn't going to be linked with the libraries necessary to use QMessageBox.

Hey ho! Compile time checks ...

JonB

@Perdrix
This is the sort of thing I was trying to discuss with you once you start trying to use qApp from a command-line executable.

I wanted to use a message box for GUI and cout for command line, but of course the command line code isn't going to be linked with the libraries necessary to use QMessageBox.

You implement this requirement via pointers-to-functions or subclassing-virtual-methods. It's a common paradigm. So that your code calls something like utilty.alert("Message") and that ends up calling either the GUI or the command-line implementation depending what function alert() pointer/virtual resolves to as set in construction/start-up. That keeps the command-line from needing to include/link with anything GUI.

Perdrix

Indeed so.

JonB

@Perdrix So you can do your "use a message box for GUI and cout for command line" if you wish. Just saying.