~oif-team/ubuntu/natty/qt4-x11/xi2.1

<td width="1">  </td><td class="postheader" valign="center"><a href="index.html"><font color="#004faf">Home</font></a> · <a href="classes.html"><font color="#004faf">All Classes</font></a> · <a href="mainclasses.html"><font color="#004faf">Main Classes</font></a> · <a href="annotated.html"><font color="#004faf">Annotated</font></a> · <a href="groups.html"><font color="#004faf">Grouped Classes</font></a> · <a href="functions.html"><font color="#004faf">Functions</font></a></td>

<td align="right" valign="top" width="230"><img src="images/trolltech-logo.png" align="right" width="203" height="32" border="0" /></td></tr></table><h1 align="center">Using the Meta-Object Compiler (moc)</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</a>.</p>

<p>The <tt>moc</tt> tool reads a C++ header file. If it finds one or more class declarations that contain the <tt>Q_OBJECT</tt> 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</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?</a></p>

<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 <a href="qobject.html#Q_PROPERTY">Q_PROPERTY</a>() macro declares an object property, while <a href="qobject.html#Q_ENUMS">Q_ENUMS</a>() declares a list of enumeration types within the class to be usable inside the <a href="properties.html">property system</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 <a href="qobject.html#Q_FLAGS">Q_FLAGS</a>() macro declares enums that are to be used as flags, i.e. OR'd together. Another macro, <a href="qobject.html#Q_CLASSINFO">Q_CLASSINFO</a>(), 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 <tt>Q_OBJECT</tt> 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>

<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</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 <tt>Q_OBJECT</tt> class declarations in header files, here is a useful makefile rule if you only use GNU make:</p>

<pre>  moc_%.cpp: %.h

moc $< -o $@</pre>

<p>If you want to write portably, you can use individual rules with the following form:</p>

<pre>  moc_foo.cpp: foo.h

moc $< -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>(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 <tt>Q_OBJECT</tt> 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 -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>

<h2>Command-Line Options</h2>

<p>Here are the command-line options supported by the moc:</p>

<tr valign="top" bgcolor="#a2c511"><th>Option</th><th>Description</th></tr>

<tr valign="top" bgcolor="#f0f0f0"><td><tt>-o<file></tt></td><td>Write output to <tt><file></tt> rather than to standard output.</td></tr>

<tr valign="top" bgcolor="#e0e0e0"><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>

100

<tr valign="top" bgcolor="#f0f0f0"><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>

101

<tr valign="top" bgcolor="#e0e0e0"><td><tt>-nw</tt></td><td>Do not generate any warnings. (Not recommended.)</td></tr>

102

<tr valign="top" bgcolor="#f0f0f0"><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>

103

<tr valign="top" bgcolor="#e0e0e0"><td><tt>-I<dir></tt></td><td>Add dir to the include path for header files.</td></tr>

104

<tr valign="top" bgcolor="#f0f0f0"><td><tt>-E</tt></td><td>Preprocess only; do not generate meta-object code.</td></tr>

105

<tr valign="top" bgcolor="#e0e0e0"><td><tt>-D<macro>[=<def>]</tt></td><td>Define macro, with optional definition.</td></tr>

106

<tr valign="top" bgcolor="#f0f0f0"><td><tt>-U<macro></tt></td><td>Undefine macro.</td></tr>

107

<tr valign="top" bgcolor="#e0e0e0"><td><tt>-h</tt></td><td>Display the usage and the list of options.</td></tr>

108

<tr valign="top" bgcolor="#f0f0f0"><td><tt>-v</tt></td><td>Display <tt>moc</tt>'s version number.</td></tr>

109

</table>

110

<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>

111

<pre>  #ifndef Q_MOC_RUN

112

...

113

#endif</pre>

114

<p>is skipped by the <tt>moc</tt>.</p>

115

116

<h2>Diagnostics</h2>

117

<p><tt>moc</tt> will warn you about a number of dangerous or illegal constructs in the <tt>Q_OBJECT</tt> class declarations.</p>

118

<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>

119

120

<h2>Limitations</h2>

121

<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>

122

<pre>  class SomeTemplate<int> : public QFrame

123

{

124

Q_OBJECT

125

...

126

127

signals:

128

void mySignal(int);

129

};</pre>

130

<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>

131

132

<h3>Multiple Inheritance Requires QObject to Be First</h3>

133

<p>If you are using multiple inheritance, <tt>moc</tt> assumes that the first inherited class is a subclass of <a href="qobject.html">QObject</a>. Also, be sure that only the first inherited class is a <a href="qobject.html">QObject</a>.</p>

134

<pre>  // correct

135

class SomeClass : public QObject, public OtherClass

136

{

137

...

138

};</pre>

139

<p>Virtual inheritance with <a href="qobject.html">QObject</a> is <i>not</i> supported.</p>

140

141

<h3>Function Pointers Cannot Be Signal or Slot Parameters</h3>

142

<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>

143

<pre>  class SomeClass : public QObject

144

{

145

Q_OBJECT

146

147

public slots:

148

void apply(void (*apply)(List *, void *), char *); // WRONG

149

};</pre>

150

<p>You can work around this restriction like this:</p>

151

<pre>  typedef void (*ApplyFunction)(List *, void *);

152

153

class SomeClass : public QObject

154

{

155

Q_OBJECT

156

157

public slots:

158

void apply(ApplyFunction, char *);

159

};</pre>

160

<p>It may sometimes be even better to replace the function pointer with inheritance and virtual functions.</p>

161

162

<h3>Type Macros Cannot Be Used for Signal and Slot Parameters</h3>

163

<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>

164

<pre>  #ifdef ultrix

165

#define SIGNEDNESS(a) unsigned a

166

#else

167

#define SIGNEDNESS(a) a

168

#endif

169

170

class Whatever : public QObject

171

{

172

Q_OBJECT

173

174

signals:

175

void someSignal(SIGNEDNESS(int));

176

};</pre>

177

<p>A macro without parameters will work.</p>

178

179

<h3>Nested Classes Cannot Have Signals or Slots</h3>

180

<p>Here's an example of the offending construct:</p>

181

<pre>  class A

182

{

183

public:

184

class B

185

{

186

Q_OBJECT

187

188

public slots: // WRONG

189

void b();

190

};

191

};</pre>

192

193

<h3>Only Signals and Slots May Appear in the <tt>signals</tt> and <tt>slots</tt> Sections of a Class</h3>

194

<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>

195

<p>See also <a href="metaobjects.html">Meta-Object System</a>, <a href="signalsandslots.html">Signals and Slots</a>, and <a href="properties.html">Qt's Property System</a>.</p>

196

197

198

199

<td width="40%" align="center"><a href="trademarks.html">Trademarks</a></td>

200

201

</tr></table></div></address></body>

202

</html>

Older »