Newsflash

2009-10-22 Press Release

On 2009-10-22 Methos Consulting has published the following press release about their support of KLAVAR!, an open source project in the Computer Aided Instruction area. It's a music sequencer using the easy-to-read Klavar music notation.

Methos Consulting Ltd

Independent IT Consultants

 

Feed Display

BBC News | News Front Page | UK Edition
Qt Libraries
Print E-mail
Written by Marco Mascioli   

Qt Classes Without MOC (almost)

This is a quick note about what I have done in order to have some Qt classes compiled without the need of the Meta Object Compiler (MOC) from Qtsoftware. It doesn't mean to be exhaustive and it could be rightly considered a dirty trick, but it did the job for me and I believe that this could be a start for an interested reader to create a more elegant solution.

The problem for me was the fact that Qtsoftware offers no official support for any type of round-trip engineering tool. That prevents me from forward- and reverse-engineer my classes from my preferred (and inexpensive) UML modeling tool.

In order to do that, the classes must be simple C++ classes, without any additional keyword.

I am working with the QT libraries, open source version, release 4.2.1 on CentOS 5.2 (virtual machine on Windows XP). I have only faced the problem of eliminating three MOC keywords from my classes: Q_OBJECT, slots and signals.

In the version of the libraries I have, the MOC operates by creating a .cpp file from the .h file of the class, usually called moc_.cpp.

Everytime we include a Qt file in our source code another file is included. In my version of the libraries it is called qobjectdefs.h and it is located in the $QTDIR/include/QtCore. In this file we can find the definition of the Q_OBJECT macro.

This file acts differently depending on the tool running and the behavior is determined by the preprocessor variable QT_MOC_RUN, probably set by the MOC itself. When compiling the file with a C++ compiler (like g++), the variable is undefined and the "MOC variables" in our source code are nullified, thus allowing the successful compilation of our classes.

However, when running the MOC, the Q_OBJECT macro expands into a set of elements (attributes and methods) that go into our code. Importantly, those elements do not depend from the definition of our class, as Q_OBJECT just acts as a string replacement. And here we can already see the opportunity: inserting those strings in our code ourselves would make the Q_OBJECT macro superfluous.

The elements defined by the macro are actually used and implemented in the .cpp file that the MOC generates, thus the need to include the generated file in the compilation of the whole executable. Of course the generated .cpp file actually depends on the definition of our class (signals, slots and their arguments), and for this reason I put "almost" without MOC in the title of this note. I don't have time to investigate the matter more, study the generated code and provide an alternative. For my objectives, I am perfectly happy to let the MOC generate the .cpp file every time I change something in the signal/slot mechanism of my class.

Despite all the limitations discussed above, we can append the MOC generated file to the definition of our class (our .cpp file). This entitles us to change the "signals" keyword into "protected" and delete the "slots" keyword in the class declaration (the .h file), ending up with a C++ class that can be compiled without qmake, but still implementing the Qt signal/slot mechanism.

In order to compile the systems using the Makefile generated by qmake just delete all the moc_xxxx.cpp files from the SOURCES list and the corresponding .o from the OBJECTS list.

I hope it helps

Last Updated ( Monday, 02 March 2009 14:15 )
 

Search Methos Consulting

Newsletter

Telemetry & Tracking applications

from Methos Consulting

on Owasys Systems

Banner

Adaptive Modules is

Our Partner for

Wireless Solutions