Andy Shaw

Qt Commercial Support Weekly #8: A Couple of QCoreApplication/QApplication Tips

12/19/2011 4:50 PM  | Posted by: Andy Shaw

This will be the last support weekly post of 2011, but there is no need to be sad as we will be back again in the new year as I am taking some (well deserved?) time off next week.

 

This week we will cover a couple of pieces related to QCoreApplication/QApplication which will hopefully be useful to some of you out there.  

 

First of all, what seemed to be a recurring related problem last week was problems connected to plugins.  As Qt is so diverse it is possible to use it in some small applications purely for doing some simple operation such as reading from the command line, converting images from one format to another or a network task that does not require a gui.  One thing that is easy to forget when it comes to this is although you may not need to call QCoreApplication::exec() or QApplication::exec() then it is still relevant to actually create a QCoreApplication/QApplication object for your application to work.

 

The reason for this is that the application object actually enables plugins to be used in your application, the obvious ones are the imageformat plugins and the sql plugins, but what can be forgotten is that some textcodecs are also implemented as plugins.  Therefore if you are trying to convert from a locale encoding (such as Japanese) then you need to have the textcodec plugins as well.  So you need to create an application object to ensure that these plugins are loaded.  You don't need to call exec() on it, as it is sufficient to just have the object existing.  This will mean that it will be able to convert to and from the different locales easily, load SQL databases and some image formats without any problem.

 

Moving on to a related topic which is subclassing QCoreApplication and QApplication, this is done a lot but what I have noticed a fair bit in the past is a subtle problem which gets missed sometimes and can cause memory corruption.  The problem is with the constructor itself. What I have seen goes something like this:

 

MyApplication::MyApplication(int argc, char **argv) : QApplication(argc, argv)

 

At first glance, this looks fine. It will build and the application will run and you may not actually hit a problem.  However, there is a subtle thing missing and that is the missing reference for the argc variable.  QApplication actually takes an int reference because it will modify the original int variable taken from the main() call.  So it should look like:

 

MyApplication::MyApplication(int &argc, char **argv) : QApplication(argc, argv)

 

This resolves the memory corruption caused by it.  So, this is certainly something to watch out for when subclassing either QCoreApplication or QApplication.

 

As you probably have noticed now, Qt Commercial 4.8.0 is now released and you can find this in your download area in the customer portal. I hope that you are all able to use it and find that it is working to your needs.  As a reminder, if you do find any problems with it, then please submit them via the customer portal.  The support team will be available through the holiday period with the exception of the 26th December (which is the only public holiday that does not fall on a weekend this year). So, we will be able to handle your queries.

 

From all of us in the Qt Commercial support team I wish you all happy holidays and I hope that 2012 brings you more and more productive results from using Qt Commercial!

Comments:

anonymous | 12/20/2011 2:15 PM
I hit the argc problem too. My app was crashing randomly after *hours* of working with it at the most weird moments when doing actions that otherwise worked perfectly. It took me years before I figured out the cause: I was accidentally rereading the doc of QApplication when suddenly I saw that ampersand in front of argc. After adding it to my own code, the crash was gone. The doc says that argc is modified, but it doesn't stress enough the fact that argc should be passed by reference, so it is damn easy to overlook this.

kkoehne | 12/21/2011 5:20 PM
Actually there's an easier workaround: Don't subclass QApplication/QCoreApplication. It's usually not needed anyway, since there are (almost) no protected methods to override.

Andy Shaw | 12/22/2011 12:08 AM
kkoehne: There are quite a few reasons to subclass it because the platform event filters are made available there and if you want to get all the events sent to the application before Qt handles them then this is the only way. In addition, if you want to do session management then you need to reimplement commitData() in QApplication. So there are often valid reasons for needing to subclass QCoreApplication/QApplication, and the argc reference is just something that has to be watched out for.

DanielM | 12/22/2011 12:33 AM
Just as a point of interest: the memory corruption issue would likely have been avoided altogether if QApplication had used an int-pointer instead of an int-reference for the "argc" parameter. In many years of C++ development, I have encountered similar issues with references that would have been avoided altogether if pointers had been used instead. As a general rule, I always prefer pointers over non-const references. This is a Qt convention too: http://doc.qt.nokia.com/qq/qq13-apis.html#pointersorreferences ... so I guess the QApplication API designer missed that one :)

Andy Shaw | 12/22/2011 8:56 AM
DanielM: That is certainly true and when the original code came in goes back to even before my time and I've been doing this for 11 years :) I can only assume however that the reason they used an int reference was because the most common usage would be to just create a QApplication object and pass in the variables from the main() function. Therefore it is easier for people to just do: QApplication a(argc, argv); Whereas to keep it as a pointer they would have to do: QApplication a(&argc, argv); Which may feel strange to people to have to do, but who knows, maybe it will be changed for Qt 5.0 or a future release.

Parthena | 1/11/2012 8:04 PM
Hey, you're the goto eexprt. Thanks for hanging out here.

Egbert | 2/21/2012 7:50 PM
A long time ago there was a fuaoms lib which got a hacked api. So a lot of people tried to get a workaround. They used the problems for their work.The author of the fuaoms lib decided to correct the problematic api and all programms using it got problems.oh yes. I can remeber the author telling the other what they should have done instead of programming

Arunkanth | 3/20/2012 4:17 PM
Thank you so much for this blog. It helped me a lot. I have been debugging to find the bug in our code which has been working fine since so many years. Now that we have started using cocoa we got this bug and I have wasted so much time thinking that the culprit is the cocoa change and finally after 3 days of debugging found that this reference issue is the issue. Thank you so much

Add new comment:

User verification Image for user verification  
     

Tags

Archive

Authors

Pasi Matilainen

Pasi is a Software Specialist working at Digia, Qt Commercial R&D and he concentrates on Mac OS X development. Pasi holds an M.Sc. degree in Information Technology from the Tampere University of Technology, Finland.

Tarja Sundqvist

Tarja is a Senior Software Engineer in the Digia, Qt Commercial Support team. She has been working in Digia for over 10 years in various positions: software development, testing, error management. Now, Tarja is focusing on helping Qt Commercial customers with their daily Qt problems on Windows and Linux platforms. Tarja holds an M.Sc. degree in Information Processing Science from the University of Oulu, Finland.

Akseli Salovaara

Akseli is a Software Specialist at Digia, Qt Commercial R&D and is responsible for the Qt Commercial releases and deliveries. Akseli holds an B.Sc. degree in Information Technology from the University of Applied Sciences in Jyväskylä, Finland.

Samuli Piippo

Samuli is a Software Specialist at Digia, Qt Commercial R&D with a concentration on  embedded Linux and RTOS development. Samuli holds an M.Sc. degree in Information Processing Science from the University of Oulu, Finland.

Katherine Barrios

Katherine is the Marketing Manager at Digia, Qt Commercial. She is responsible for getting the word out about Qt Commercial to the Qt ecosystem and working together with our customers and the Qt community to further extend the love for Qt on desktop and embedded. She was previously employed at Nokia, Qt Development Frameworks as Program Marketing Manager and is based in Oslo, Norway.

Sami Makkonen

Sami is a Senior Product Manager working at Digia, Qt Commercial R&D and he is responsible for the product planning including new feature development and enhancements to existing functionality. Sami holds an M.Sc.(Econ.) degree in Computer Science.

Andy Shaw

Andy is the Head of Support at Digia, Qt Commercial and has been working with Qt and supporting customers using Qt for 11 years.  He thrives on solving customer problems and getting feedback from them.

Tuukka Turunen

Tuukka is the Director of R&D at Digia, Qt Commercial and is responsible for the planning, creation, verification and delivery of the Qt Commercial product. Tuukka holds a M.Sc.(Eng) and Licentiate of Technology degrees in Computer Science.

Qt Commercial Team