Usage of QApplication and QCoreApplication

This is the background of the story. We will always see such statements when writing the QT program or before we start to write the QT program.

QApplication app(argc, argv);

What is this? The QCoreApplication class inherits the QCoreApplication class, while the QCoreApplication class inherits the QCoreApplication class.

QObject is the most basic base class in QT, that is, the foundation of QT.

Let's start with this in the header file.

class Q_CORE_EXPORT QCoreApplication : public QObject

What is Q_CORE_EXPORT? If you define the DLL symbol when writing a dynamic library, Q_GUI_EXPORT is the export function or class

If the Dll symbol is not defined in the application, Q_GUI_EXPORT is the import class or function.

We wrote the command line instead of writing a dynamic library. Below are some definitions of functions and variables.

Stunned

QCoreApplication *  instance ()

Define an instance pointing to itself, huh? What is it like? Isn't it possible to call itself? The implementation is in the class, because it is static

static QCoreApplication *instance() { return self; }

Is to return a self

static QCoreApplication *self;

Is a private static member variable, implemented outside the class

QCoreApplication *QCoreApplication::self = 0;

Now I know what self is doing, but here I have a question, even QCoreApplication has not been created.

Where does the pointer to QCoreApplication exist? The personal explanation here is that the creation of static members should be created by class

It already exists before. As for this point, we will not consider it for the moment. Maybe the system will solve this problem. Here we will refer to it

Needle.

It is necessary to take a look at the constructor of the QCoreApplication class.

QCoreApplication::QCoreApplication(int &argc, char **argv)    : QObject(*new QCoreApplicationPrivate(argc, argv)){    init();    QCoreApplicationPrivate::eventDispatcher->startingUp();#if defined(Q_OS_SYMBIAN) && !defined(QT_NO_LIBRARY)    // Refresh factoryloader, as text codecs are requested during lib path    // resolving process and won't be therefore properly loaded.    // Unknown if this is symbian specific issue.    QFactoryLoader::refreshAll();#endif#if defined(Q_OS_SYMBIAN) && !defined(QT_NO_SYSTEMLOCALE)    d_func()->symbianInit();#endif}

The following is a bit dizzy. Here we only look at init (); this function is under the constructor, and there is more code here,

Here, only one line of attention is written.

void QCoreApplication::init(){     QCoreApplication::self = this;}

Here, self is assigned a value, which enables this self to point to the current object, rather than pointing to nothing. This self can be

To replace the current object, of course, this can only be used within the class, because self is private, should I be defined to be used outside the class?

A common member function or something. Leave the question here first.

The static member variable self still does not solve the problem of why this problem occurs. It turns out that we can see it in the previous line of the class definition.

To such code

#define qApp QCoreApplication::instance()

When a qApp macro is defined, this macro becomes a pointer pointing to itself. What is the purpose of this process?

When we define the QCoreApplication app (argc, argv) in the main program; when the object is, we do not need to use the qApp

Macro, but what should I do if the main function uses this object? This is troublesome. QT uses this to point to its own East Region.

East is to help us solve the problem that we cannot find the object by using the app outside the main function. Okay, you can

Use qApp. Will there be any problems? Is this thing in memory? Hey, this is static. It's in the memory. It's big.

Boldly use this macro pointer to point to your own, as long as the app does not parse this stuff, it has been in the memory.

The following describes the QApplication, which is inherited from QCoreApplication,

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

There is such code before the class definition. Here we also take the pointer self pointing to ourselves, but we need to make a type conversion. As to whether this type conversion is secure, I think it should be safe, because it is equivalent to converting from the base class to the derived class, some of the base classes should be copied, but it is not clear whether the static here will cause this problem. In short, after conversion, this qApp can be used outside the main function.

It should also be noted that this QCoreApplication is not a singleton problem. Many people on the internet think it is Singleton, and many people agree with it. However, if I have practiced it, it should not be Singleton.

for(int i = 0 ; i < 3 ; ++i){    QCoreApplication app;}

This operation is allowed here. Because the previous structure has been analyzed, only one function can be created in QT. Obviously not, the implementation of Singleton is generally implemented through private constructor. The constructor here is a common one, obviously not the pace of Singleton.

This article from the "selling cute programmers" blog, please be sure to keep this source http://7677869.blog.51cto.com/7667869/1288735