<?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>
distrib
>
Mandriva
>
2010.0
>
i586
>
media
>
contrib-release
>
by-pkgid
>
a6711891ce757817bba854bf3f25205a
>
files
>
1787
