File: moc.doc

package info (click to toggle)
qt-x11-free 3:3.3.8b-7
  • links: PTS, VCS
  • area: main
  • in suites: squeeze
  • size: 82,260 kB
  • ctags: 72,611
  • sloc: cpp: 456,781; ansic: 129,082; sh: 11,455; yacc: 2,947; xml: 766; makefile: 566; perl: 495; lex: 458; sql: 29; lisp: 13
file content (513 lines) | stat: -rw-r--r-- 15,474 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
/****************************************************************************
**
** Moc usage, expanded from the manual page
**
** Copyright (C) 1992-2008 Trolltech ASA.  All rights reserved.
**
** This file is part of the Qt GUI Toolkit.
**
** This file may be used under the terms of the GNU General
** Public License versions 2.0 or 3.0 as published by the Free
** Software Foundation and appearing in the files LICENSE.GPL2
** and LICENSE.GPL3 included in the packaging of this file.
** Alternatively you may (at your option) use any later version
** of the GNU General Public License if such license has been
** publicly approved by Trolltech ASA (or its successors, if any)
** and the KDE Free Qt Foundation.
**
** Please review the following information to ensure GNU General
** Public Licensing requirements will be met:
** http://trolltech.com/products/qt/licenses/licensing/opensource/.
** If you are unsure which license is appropriate for your use, please
** review the following information:
** http://trolltech.com/products/qt/licenses/licensing/licensingoverview
** or contact the sales department at sales@trolltech.com.
**
** This file may be used under the terms of the Q Public License as
** defined by Trolltech ASA and appearing in the file LICENSE.QPL
** included in the packaging of this file.  Licensees holding valid Qt
** Commercial licenses may use this file in accordance with the Qt
** Commercial License Agreement provided with the Software.
**
** This file is provided "AS IS" with NO WARRANTY OF ANY KIND,
** INCLUDING THE WARRANTIES OF DESIGN, MERCHANTABILITY AND FITNESS FOR
** A PARTICULAR PURPOSE. Trolltech reserves all rights not granted
** herein.
**
**********************************************************************/

// Note: Text in this file must also be copied to the moc man page:
// src/moc/moc.1

/*!
\page moc.html

\title Using the Meta Object Compiler

\keyword moc

The Meta Object Compiler, moc among friends, is the program which
handles Qt's \link metaobjects.html C++ extensions.\endlink

The moc reads a C++ source file. If it finds one or more class
declarations that contain the Q_OBJECT macro, it produces another
C++ source file which contains the meta object code for the classes
that use the Q_OBJECT macro. Among other things, meta object code is
required for the signal/slot mechanism, runtime type information and
the dynamic property system.

The C++ source file generated by the moc must be compiled and linked
with the implementation of the class (or it can be #included into the
class's source file).

If you use \link qmake-manual.book qmake\endlink 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 moc, see \link templates.html Why doesn't Qt
use templates for signals and slots?\endlink.

\section1 Usage

The moc is typically used with an input file containing class declarations
like this:

\code
    class MyClass : public QObject
    {
        Q_OBJECT
    public:
        MyClass( QObject * parent=0, const char * name=0 );
        ~MyClass();

    signals:
	void mySignal();

    public slots:
	void mySlot();

    };
\endcode

In addition to the signals and slots shown above, the moc 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 
\link properties.html property system\endlink.  In this particular
case we declare a property of the enumeration type \c Priority that is
also called "priority" and has a get function \c priority() and a set
function \c setPriority().

\code
    class MyClass : public QObject
    {
        Q_OBJECT
        Q_PROPERTY( Priority priority READ priority WRITE setPriority )
        Q_ENUMS( Priority )
    public:
        MyClass( QObject * parent=0, const char * name=0 );
        ~MyClass();

        enum Priority { High, Low, VeryHigh, VeryLow };
        void setPriority( Priority );
        Priority priority() const;
    };
\endcode

Properties can be modified in subclasses with the Q_OVERRIDE
macro. The Q_SETS macro declares enums that are to be used as
sets, i.e. OR'ed together. Another macro, Q_CLASSINFO, can be used to
attach additional name/value-pairs to the class' meta object:

\code
    class MyClass : public QObject
    {
        Q_OBJECT
        Q_CLASSINFO( "Author", "Oscar Peterson")
        Q_CLASSINFO( "Status", "Active")
    public:
        MyClass( QObject * parent=0, const char * name=0 );
        ~MyClass();
    };
\endcode

The three concepts, signals and slots, properties and class
meta-data, can be combined.

The output produced by the moc must be compiled and linked, just like
the other C++ code in your program; otherwise the build will fail in
the final link phase. By convention, this is done in one of the
following two ways:

<dl>

<dt><b>Method A: The class declaration is found in a header
(\e .h) file</b>

<dd>If the class declaration above is found in the file
\e myclass.h, the moc output should be put in a file called
\e moc_myclass.cpp. This file should then be compiled as
usual, resulting in an object file \e moc_myclass.o (on Unix)
or \e moc_myclass.obj (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.


<dt><b>Method B: The class declaration is found in an implementation
(\e .cpp) file</b>

<dd>If the class declaration above is found in the file
\e myclass.cpp, the moc output should be put in a file called
\e myclass.moc. This file should be #included in the
implementation file, i.e. \e myclass.cpp should contain the
line
\code
    #include "myclass.moc"
\endcode
at the end. This will cause the moc-generated code to be compiled and
linked together with the normal class definition in \e myclass.cpp, so
it is not necessary to compile and link it separately, as in Method A.

</dl>

Method A is the normal method. Method B can be used in cases where you
want the implementation file to be self-contained, or in cases where
the Q_OBJECT class is implementation-internal and thus should not be
visible in the header file.


\section1 Automating moc Usage with Makefiles

For anything but the simplest test programs, it is recommended that
you automate running the moc. By adding some rules to your program's
Makefile, \e make can take care of running moc when necessary and
handling the moc output.

We recommend using Trolltech's free makefile generation tool, \link
qmake-manual.book qmake\endlink, for building your Makefiles. This tool
recognizes both Method A and B style source files, and generates a
Makefile that does all the necessary moc handling.

If you want to create your Makefiles yourself, here are some tips on
how to include moc handling.

For Q_OBJECT class declarations in header files, here is a useful
makefile rule if you only use GNU make:

\code
    moc_%.cpp: %.h
            moc $< -o $@
\endcode

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

\code
    moc_NAME.cpp: NAME.h
            moc $< -o $@
\endcode

You must also remember to add \e moc_NAME.cpp to your SOURCES
(substitute your favorite name) variable and \e moc_NAME.o or
\e moc_NAME.obj to your OBJECTS variable.

(While we prefer to name our C++ source files .cpp, the moc doesn't
care, so you can use .C, .cc, .CC, .cxx or even .c++ if you
prefer.)

For Q_OBJECT class declarations in implementation (.cpp) files, we
suggest a makefile rule like this:

\code
    NAME.o: NAME.moc

    NAME.moc: NAME.cpp
            moc -i $< -o $@
\endcode

This guarantees that make will run the moc before it compiles
\e NAME.cpp. You can then put

\code
    #include "NAME.moc"
\endcode

at the end of \e NAME.cpp, where all the classes declared in
that file are fully known.


\section1 Invoking moc

Here are the command-line options supported by the moc:

\table
\header \i Option \i Meaning
\row
\i -o \e file 
\i Write output to \e file rather than to stdout.
\row
\i -f 
\i Force the generation of an #include statement in the
output.  This is the default for files whose name matches the regular
expression \.[hH][^.]* (i.e. the extension starts with H or h).  This
option is only useful if you have header files that do not follow the
standard naming conventions.
\row
\i -i 
\i Do not generate an #include 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 #include the meta object
code in the .cpp
file.  If both -i and -f are present, the last one wins.
\row
\i -nw 
\i Do not generate any warnings.  Not recommended.
\row
\i -ldbg 
\i Write a flood of lex debug information to stdout.
\row
\i -p \e path 
\i Makes the moc prepend \e {path}/ to
the file name in the generated #include statement (if one is
generated).
\row
\i -q \e path 
\i Makes the moc prepend \e {path}/ to
the file name of qt #include files in the generated code.
\endtable

You can explicitly tell the moc not to parse parts of a header
file. It recognizes any C++ comment (//) that contains the substrings
MOC_SKIP_BEGIN or MOC_SKIP_END. They work as you would expect and you
can have several levels of them. The net result as seen by the moc is
as if you had removed all lines between a MOC_SKIP_BEGIN and a
MOC_SKIP_END.


\section1 Diagnostics

The moc will warn you about a number of dangerous or illegal
constructs in the Q_OBJECT class declarations.

If you get linkage errors in the final building phase of your
program, saying that YourClass::className() is undefined or that
YourClass lacks a vtbl, something has been done wrong. Most often,
you have forgotten to compile or #include the moc-generated C++ code, or
(in the former case) include that object file in the link command.


\section1 Limitations

The moc does not expand #include or #define, it simply skips any
preprocessor directives it encounters. This is regrettable, but is
not usually a problem in practice.

The moc does not handle all of C++.  The main problem is that class
templates cannot have signals or slots. Here is an example:

\code
    class SomeTemplate<int> : public QFrame {
        Q_OBJECT
	...
    signals:
        void bugInMocDetected( int );
    };
\endcode

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.

\section2 Multiple inheritance requires QObject to be first

If you are using multiple inheritance, moc assumes that the \e first
inherited class is a subclass of QObject.  Also, be sure that \e only
the first inherited class is a QObject.

\code
    class SomeClass : public QObject, public OtherClass {
	...
    };
\endcode

(This limitation is almost impossible to remove; since the moc does not expand
#include or #define, it cannot find out which one of the base classes
is a QObject.)

\section2 Function pointers cannot be arguments to signals or slots

In most cases where you would consider using function pointers as
signal/slot arguments, we think inheritance is a better alternative.
Here is an example of illegal syntax:

\code
    class SomeClass : public QObject {
        Q_OBJECT
	...
    public slots:
	// illegal
	void apply( void (*apply)(List *, void *), char * );
    };
\endcode

You can work around this restriction like this:
\code
    typedef void (*ApplyFunctionType)( List *, void * );

    class SomeClass : public QObject {
        Q_OBJECT
	...
    public slots:
        void apply( ApplyFunctionType, char * );
    };
\endcode

It may sometimes be even better to replace the function pointer with
inheritance and virtual functions, signals or slots.

\section2 Friend declarations cannot be placed in signals or slots sections

Sometimes it will work, but in general, friend declarations cannot be
placed in signals or slots sections.  Put them in the private,
protected or public sections instead.  Here is an example of the
illegal syntax:

\code
    class SomeClass : public QObject {
        Q_OBJECT
	...
    signals:
        friend class ClassTemplate<char>; // WRONG
    };
\endcode

\section2 Signals and slots cannot be upgraded

The C++ feature of upgrading an inherited member function to
public status is not extended to cover signals and slots.  Here is an
illegal example:

\code
    class Whatever : public QButtonGroup {
	...
    public slots:
	QButtonGroup::buttonPressed; // WRONG
	...
    };
\endcode

The QButtonGroup::buttonPressed() slot is protected.

C++ quiz: What happens if you try to upgrade a protected member
function which is overloaded?
\list 1
\i All the functions are overloaded.
\i That is not legal C++.
\endlist

\omit
C++ ARM, section r.11.3
\endomit

\section2 Type macros cannot be used for signal and slot parameters

Since the moc does not expand #define, type macros that take an argument
will not work in signals and slots. Here is an illegal example:

\code
    #ifdef ultrix
    #define SIGNEDNESS(a) unsigned a
    #else
    #define SIGNEDNESS(a) a
    #endif

    class Whatever : public QObject {
	...
    signals:
        void someSignal( SIGNEDNESS(int) );
	...
    };
\endcode

A #define without parameters will work as expected.

\section2 Nested classes cannot be in the signals or slots sections nor have
signals or slots

Here's an example:

\code
    class A {
	Q_OBJECT
    public:
        class B {
	public slots:   // WRONG
	    void b();
	    ...
        };
    signals:
        class B {       // WRONG
	    void b();
	    ...
        }:
    };
\endcode

\section2 Constructors cannot be used in signals or slots sections

It is a mystery to us why anyone would put a constructor in
either the signals or slots sections.  You can't anyway (except
that it happens to work in some cases).  Put them in private,
protected or public sections, where they belong.  Here is an example
of the illegal syntax:

\code
    class SomeClass : public QObject {
	Q_OBJECT
    public slots:
	SomeClass( QObject *parent, const char *name )
	    : QObject( parent, name ) { } // WRONG
	...
    };
\endcode

\section2 Properties need to be declared before the public section that
contains the respective get and set functions

Declaring the first property within or after the public section that
contains the type definition and the respective get and set functions
does not work as expected. The moc will complain that it can neither
find the functions nor resolve the type. Here is an example of the
illegal syntax:

\code
    class SomeClass : public QObject {
        Q_OBJECT
    public:
	...
        Q_PROPERTY( Priority priority READ priority WRITE setPriority ) // WRONG
        Q_ENUMS( Priority ) // WRONG
        enum Priority { High, Low, VeryHigh, VeryLow };
        void setPriority( Priority );
        Priority priority() const;
	...
    };
\endcode

Work around this limitation by declaring all properties at the
beginning of the class declaration, right after Q_OBJECT:

\code
    class SomeClass : public QObject {
        Q_OBJECT
        Q_PROPERTY( Priority priority READ priority WRITE setPriority )
        Q_ENUMS( Priority )
    public:
	...
        enum Priority { High, Low, VeryHigh, VeryLow };
        void setPriority( Priority );
        Priority priority() const;
	...
    };
\endcode

*/