Implementing Thread Safe logging in my Qt Application

Absurd

I want to add some logging mechanism to my application.
I am uncertain regarding the implementation though, and would really appreciate the consult of the forum members.

So, I thought it will be best to first define to myself what capabilities do I want the logger to have.

It should be/have:

Thread safe
Multiple levels of logging
Completely removable by a compilation flag
Flexible - in the sense that I could easily change it (both in app launching - using console args and in compilation - using compilation flags) such that it will be able to log to any stream I'll choose (stdout/stderr/stream)
As fast as it can be - as I don't want any hangs in the rendering of the App's GUI over this logger
And of course - like any other thing - as loosely coupled as possible from the agents that use it (I may want to use it in a second project I want to implement)

Do you think it is possible to implement Logger that will satisfy all the above?

So this is what I have in mind:
In order to avoid locking mechanism altogether (good for bullet 5 above), the Logger will live on its own thread - and that thread will be the only thread that accesses the streams (sdtout/stderr/file), and will implement three slots for the three levels of logging (satisfies 2).
These slots will be invoked by the emission of signals, and this - together with the fact that Logger runs on its own thread - will guarantee Thread Safety (satisfies 1).
I think I can make bullet 4 work with default values for constructors and function overloading and/or compilation macros.

My problem is with 6:
Every class that wants to Log something, must:

declare the appropriate signals
connect these signals to the Logger's slots
This is impossible. I have a lot of QWidget's used in my app, and I cannot go and add this for everyone.

Your thoughts? Any advises? Do you see problems with the above approach?

Thanks.

SGaist

Hi,

What about Qt's Logging Categories ?
You can combine that with qInstallMessageHandler to queue all your messages to your dedicated thread.

Absurd

@SGaist Sorry... I forgot to mention; I am using Qt4. The above is only available since Qt5.2.

kshegunov

@Absurd said in Implementing Thread Safe logging in my Qt Application:

Sorry... I forgot to mention; I am using Qt4. The above is only available since Qt5.2.

Any specific reason to use an EOL product version for new development?

Absurd

@kshegunov Yes; qt4 is installed by default on all of our servers (don't know why, it just how it is), as oppose to qt5 which I'll have to install.
I want my app to run without any additional installations.

Christian Ehrlicher

When I would be your server admin I would not allow you to add a new application with a library which last was updated more than 4 years ago... but if you want to develop with such an old library you have to do such work on your own...
Otherwise I would have suggested to use log4qt from here

kshegunov

@Absurd said in Implementing Thread Safe logging in my Qt Application:

I want my app to run without any additional installations.

You should rethink that, as Qt 4.8.7 was released 3 years ago and is the last patch release of the Qt 4.8 minor release, which itself was released over 8 years ago. You should either upgrade your server(s), or build Qt 5 yourself and use it for new development. Otherwise your approach (in the OP) appears sound.

Absurd

@Christian-Ehrlicher
We have few more tools that are implemented with qt4 (for historic reasons, I believe).
What harm could that do? (developing with an old library)

Thanks, I'll give logqt4 a try...

Christian Ehrlicher

Security-wise it's a nightmare to use a library which is not up-to-date.
And log4qt only works with Qt5(.9)and above

Absurd

@Christian-Ehrlicher we use these machines for internal debug only (so are our tools)...

aha_1980

@Absurd as you have to deploy your app to the server anyway, why not deploy Qt 5 together with them?

All existing apps stay unchanged, but the new ones start using their own libraries.

Qt Creator does it like this, for example.

Absurd

@aha_1980 to be honest, I'd prefer working with qt5, and I also tried to install it on one of our machines before starting the project, but I ran into so many problems and it was so complicated so I gave up.

Now it's too late anyway, because I wrote so much code in qt4... (unless qt5 is completely backward compatible with qt4)

aha_1980

@Absurd

Now it's too late anyway, because I wrote so much code in qt4...

For sure not ;)

(unless qt5 is completely backward compatible with qt4)

Not completely, but in many ways. I've a lot of tools compatible with both versions. That needs a few #ifdef, but that's it.

I'd recommend doing the upgrade incrementally, because Qt 6 will appear in 2..3 years and Qt 5 will be similar to what Qt 4 is now.

Absurd

@aha_1980 Thanks. I'll give the qt5 installation one more try.