<?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <!-- /home/gvatteka/dev/qt-4.3/doc/src/moc.qdoc --> <head> <title>Using the Meta-Object Compiler (moc)</title> <link href="classic.css" rel="stylesheet" type="text/css" /> </head> <body> <h1 align="center">Using the Meta-Object Compiler (moc)<br /><small></small></h1> <a name="moc"></a><p>The Meta-Object Compiler, <tt>moc</tt>, is the program that handles <a href="metaobjects.html">Qt's C++ extensions</tt></a>.</p> <p>The <tt>moc</tt> tool reads a C++ header file. If it finds one or more class declarations that contain the Q_OBJECT macro, it produces a C++ source file containing the meta-object code for those classes. Among other things, meta-object code is required for the signals and slots mechanism, the run-time type information, and the dynamic property system.</p> <p>The C++ source file generated by <tt>moc</tt> must be compiled and linked with the implementation of the class.</p> <p>If you use <a href="qmake-manual.html#qmake">qmake</tt></a> to create your makefiles, build rules will be included that call the moc when required, so you will not need to use the moc directly. For more background information on <tt>moc</tt>, see <a href="templates.html">Why doesn't Qt use templates for signals and slots?</tt></a></p> <a name="usage"></a> <h2>Usage</h2> <p><tt>moc</tt> is typically used with an input file containing class declarations like this:</p> <pre> class MyClass : public QObject { Q_OBJECT public: MyClass(QObject *parent = 0); ~MyClass(); signals: void mySignal(); public slots: void mySlot(); };</pre> <p>In addition to the signals and slots shown above, <tt>moc</tt> also implements object properties as in the next example. The Q_PROPERTY() macro declares an object property, while Q_ENUMS() declares a list of enumeration types within the class to be usable inside the <a href="properties.html">property system</tt></a>.</p> <p>In the following example, we declare a property of the enumeration type <tt>Priority</tt> that is also called <tt>priority</tt> and has a get function <tt>priority()</tt> and a set function <tt>setPriority()</tt>.</p> <pre> class MyClass : public QObject { Q_OBJECT Q_PROPERTY(Priority priority READ priority WRITE setPriority) Q_ENUMS(Priority) public: enum Priority { High, Low, VeryHigh, VeryLow }; MyClass(QObject *parent = 0); ~MyClass(); void setPriority(Priority priority); Priority priority() const; };</pre> <p>The Q_FLAGS() macro declares enums that are to be used as flags, i.e. OR'd together. Another macro, Q_CLASSINFO(), allows you to attach additional name/value pairs to the class's meta-object:</p> <pre> class MyClass : public QObject { Q_OBJECT Q_CLASSINFO("Author", "Oscar Peterson") Q_CLASSINFO("Status", "Active") public: MyClass(QObject *parent = 0); ~MyClass(); };</pre> <p>The output produced by <tt>moc</tt> must be compiled and linked, just like the other C++ code in your program; otherwise, the build will fail in the final link phase. If you use <tt>qmake</tt>, this is done automatically. Whenever <tt>qmake</tt> is run, it parses the project's header files and generates make rules to invoke <tt>moc</tt> for those files that contain a Q_OBJECT macro.</p> <p>If the class declaration is found in the file <tt>myclass.h</tt>, the moc output should be put in a file called <tt>moc_myclass.cpp</tt>. This file should then be compiled as usual, resulting in an object file, e.g., <tt>moc_myclass.obj</tt> on Windows. This object should then be included in the list of object files that are linked together in the final building phase of the program.</p> <a name="writing-make-rules-for-invoking"></a> <h2>Writing Make Rules for Invoking <tt>moc</tt></h2> <p>For anything but the simplest test programs, it is recommended that you automate running the <tt>moc</tt>. By adding some rules to your program's makefile, <tt>make</tt> can take care of running moc when necessary and handling the moc output.</p> <p>We recommend using Trolltech's makefile generation tool, <a href="qmake-manual.html#qmake">qmake</tt></a>, for building your makefiles. This tool generates a makefile that does all the necessary <tt>moc</tt> handling.</p> <p>If you want to create your makefiles yourself, here are some tips on how to include moc handling.</p> <p>For Q_OBJECT class declarations in header files, here is a useful makefile rule if you only use GNU make:</p> <pre> moc_%.cpp: %.h moc $(DEFINES) $(INCPATH) $< -o $@</pre> <p>If you want to write portably, you can use individual rules of the following form:</p> <pre> moc_foo.cpp: foo.h moc $(DEFINES) $(INCPATH) $< -o $@</pre> <p>You must also remember to add <tt>moc_foo.cpp</tt> to your <tt>SOURCES</tt> (substitute your favorite name) variable and <tt>moc_foo.o</tt> or <tt>moc_foo.obj</tt> to your <tt>OBJECTS</tt> variable.</p> <p>Both examples assume that <tt>$(DEFINES)</tt> and <tt>$(INCPATH)</tt> expand to the define and include path options that are passed to the C++ compiler. These are required by <tt>moc</tt> to preprocess the source files.</p> <p>While we prefer to name our C++ source files <tt>.cpp</tt>, you can use any other extension, such as <tt>.C</tt>, <tt>.cc</tt>, <tt>.CC</tt>, <tt>.cxx</tt>, and <tt>.c++</tt>, if you prefer.</p> <p>For Q_OBJECT class declarations in implementation (<tt>.cpp</tt>) files, we suggest a makefile rule like this:</p> <pre> foo.o: foo.moc foo.moc: foo.cpp moc $(DEFINES) $(INCPATH) -i $< -o $@</pre> <p>This guarantees that make will run the moc before it compiles <tt>foo.cpp</tt>. You can then put</p> <pre> #include "foo.moc"</pre> <p>at the end of <tt>foo.cpp</tt>, where all the classes declared in that file are fully known.</p> <a name="command-line-options"></a> <h2>Command-Line Options</h2> <p>Here are the command-line options supported by the moc:</p> <p><table align="center" cellpadding="2" cellspacing="1" border="0"> <thead><tr valign="top" class="qt-style"><th>Option</th><th>Description</th></tr></thead> <tr valign="top" class="odd"><td><tt>-o<file></tt></td><td>Write output to <tt><file></tt> rather than to standard output.</td></tr> <tr valign="top" class="even"><td><tt>-f[<file>]</tt></td><td>Force the generation of an <tt>#include</tt> statement in the output. This is the default for header files whose extension starts with <tt>H</tt> or <tt>h</tt>. This option is useful if you have header files that do not follow the standard naming conventions. The <tt><file></tt> part is optional.</td></tr> <tr valign="top" class="odd"><td><tt>-i</tt></td><td>Do not generate an <tt>#include</tt> statement in the output. This may be used to run the moc on on a C++ file containing one or more class declarations. You should then <tt>#include</tt> the meta-object code in the <tt>.cpp</tt> file.</td></tr> <tr valign="top" class="even"><td><tt>-nw</tt></td><td>Do not generate any warnings. (Not recommended.)</td></tr> <tr valign="top" class="odd"><td><tt>-p<path></tt></td><td>Makes the moc prepend <tt><path>/</tt> to the file name in the generated <tt>#include</tt> statement.</td></tr> <tr valign="top" class="even"><td><tt>-I<dir></tt></td><td>Add dir to the include path for header files.</td></tr> <tr valign="top" class="odd"><td><tt>-E</tt></td><td>Preprocess only; do not generate meta-object code.</td></tr> <tr valign="top" class="even"><td><tt>-D<macro>[=<def>]</tt></td><td>Define macro, with optional definition.</td></tr> <tr valign="top" class="odd"><td><tt>-U<macro></tt></td><td>Undefine macro.</td></tr> <tr valign="top" class="even"><td><tt>-h</tt></td><td>Display the usage and the list of options.</td></tr> <tr valign="top" class="odd"><td><tt>-v</tt></td><td>Display <tt>moc</tt>'s version number.</td></tr> </table></p> <p>You can explicitly tell the moc not to parse parts of a header file. <tt>moc</tt> defines the preprocessor symbol <tt>Q_MOC_RUN</tt>. Any code surrounded by</p> <pre> #ifndef Q_MOC_RUN ... #endif</pre> <p>is skipped by the <tt>moc</tt>.</p> <a name="diagnostics"></a> <h2>Diagnostics</h2> <p><tt>moc</tt> will warn you about a number of dangerous or illegal constructs in the Q_OBJECT class declarations.</p> <p>If you get linkage errors in the final building phase of your program, saying that <tt>YourClass::className()</tt> is undefined or that <tt>YourClass</tt> lacks a vtable, something has been done wrong. Most often, you have forgotten to compile or <tt>#include</tt> the moc-generated C++ code, or (in the former case) include that object file in the link command. If you use <tt>qmake</tt>, try rerunning it to update your makefile. This should do the trick.</p> <a name="limitations"></a> <h2>Limitations</h2> <p><tt>moc</tt> does not handle all of C++. The main problem is that class templates cannot have signals or slots. Here is an example:</p> <pre> class SomeTemplate<int> : public QFrame { Q_OBJECT ... signals: void mySignal(int); };</pre> <p>Another limitation is that moc does not expand macros, so you for example cannot use a macro to declare a signal/slot or use one to define a base class for a <a href="core/QObject.html"><tt>QObject</tt></a>.</p> <p>Less importantly, the following constructs are illegal. All of them have alternatives which we think are usually better, so removing these limitations is not a high priority for us.</p> <a name="multiple-inheritance-requires-qobject-to-be-first"></a> <h3>Multiple Inheritance Requires QObject to Be First</h3> <p>If you are using multiple inheritance, <tt>moc</tt> assumes that the first inherited class is a subclass of <a href="core/QObject.html"><tt>QObject</tt></a>. Also, be sure that only the first inherited class is a <a href="core/QObject.html"><tt>QObject</tt></a>.</p> <pre><span class="comment"> // correct</span> class SomeClass : public QObject, public OtherClass { ... };</pre> <p>Virtual inheritance with <a href="core/QObject.html"><tt>QObject</tt></a> is <i>not</i> supported.</p> <a name="function-pointers-cannot-be-signal-or-slot-parameters"></a> <h3>Function Pointers Cannot Be Signal or Slot Parameters</h3> <p>In most cases where you would consider using function pointers as signal or slot parameters, we think inheritance is a better alternative. Here is an example of illegal syntax:</p> <pre> class SomeClass : public QObject { Q_OBJECT public slots: void apply(void (*apply)(List *, void *), char *); <span class="comment">// WRONG</span> };</pre> <p>You can work around this restriction like this:</p> <pre> typedef void (*ApplyFunction)(List *, void *); class SomeClass : public QObject { Q_OBJECT public slots: void apply(ApplyFunction, char *); };</pre> <p>It may sometimes be even better to replace the function pointer with inheritance and virtual functions.</p> <a name="enums-and-typedefs-must-be-fully-qualified-for-signal-and-slot-parameters"></a> <h3>Enums and Typedefs Must Be Fully Qualified for Signal and Slot Parameters</h3> <p>When checking the signatures of its arguments, QObject::connect() compares the data types literally. Thus, Alignment</tt> and Qt::Alignment</tt> are treated as two distinct types. To work around this limitation, make sure to fully qualify the data types when declaring signals and slots, and when establishing connections. For example:</p> <pre> class MyClass : public QObject { Q_OBJECT enum Error { ConnectionRefused, RemoteHostClosed, UnknownError }; signals: void stateChanged(MyClass::Error error); };</pre> <a name="type-macros-cannot-be-used-for-signal-and-slot-parameters"></a> <h3>Type Macros Cannot Be Used for Signal and Slot Parameters</h3> <p>Since <tt>moc</tt> doesn't expand <tt>#define</tt>s, type macros that take an argument will not work in signals and slots. Here is an illegal example:</p> <pre> #ifdef ultrix #define SIGNEDNESS(a) unsigned a #else #define SIGNEDNESS(a) a #endif class Whatever : public QObject { Q_OBJECT signals: void someSignal(SIGNEDNESS(int)); };</pre> <p>A macro without parameters will work.</p> <a name="nested-classes-cannot-have-signals-or-slots"></a> <h3>Nested Classes Cannot Have Signals or Slots</h3> <p>Here's an example of the offending construct:</p> <pre> class A { public: class B { Q_OBJECT public slots: <span class="comment">// WRONG</span> void b(); }; };</pre> <a name="signal-slot-return-types-cannot-be-references"></a> <h3>Signal/Slot return types cannot be references</h3> <p>Signals and slots can have return types, but signals or slots returning references will be treated as returning void.</p> <a name="only-signals-and-slots-may-appear-in-the-and-sections-of-a-class"></a> <h3>Only Signals and Slots May Appear in the <tt>signals</tt> and <tt>slots</tt> Sections of a Class</h3> <p><tt>moc</tt> will complain if you try to put other constructs in the <tt>signals</tt> or <tt>slots</tt> sections of a class than signals and slots.</p> <dl> <dt><b>See Also:</b></dt> <dd><a href="metaobjects.html">Meta-Object System</tt></a>, <a href="qtjambi-signalsandslots.html">Signals and Slots</tt></a>, <a href="properties.html">Qt's Property System</tt></a></dd> </dl> <p /><address><hr /><div align="center"> <table width="100%" cellspacing="0" border="0"><tr class="address"> <td width="30%">Copyright © 2007 <a href="trolltech.html">Trolltech</a></td> <td width="40%" align="center"><a href="trademarks.html">Trademarks</a></td> <td width="30%" align="right"><div align="right">Qt Jambi </div></td> </tr></table></div></address></body> </html>