File: moc.html

package info (click to toggle)
qt-embedded 2.3.2-3
links: PTS
area: main
in suites: woody
size: 68,608 kB
ctags: 45,998
sloc: cpp: 276,654; ansic: 71,987; makefile: 29,074; sh: 12,305; yacc: 2,465; python: 1,863; perl: 481; lex: 480; xml: 68; lisp: 15
file content (562 lines) | stat: -rw-r--r-- 18,920 bytes
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Qt Toolkit -  Using the Meta Object Compiler</title><style type="text/css"><!--
h3.fn,span.fn { margin-left: 1cm; text-indent: -1cm; }
a:link { color: #004faf; text-decoration: none }
a:visited { color: #672967; text-decoration: none }body { background: white; color: black; }
--></style></head><body bgcolor="#ffffff">
<p>
<table width="100%">
<tr><td><a href="index.html">
<img width="100" height="100" src="qtlogo.png"
alt="Home" border="0"><img width="100"
height="100" src="face.png" alt="Home" border="0">
</a><td valign=top><div align=right><img src="dochead.png" width="472" height="27"><br>
<a href="classes.html"><b>Classes</b></a>
-<a href="annotated.html">Annotated</a>
- <a href="hierarchy.html">Tree</a>
-<a href="functions.html">Functions</a>
-<a href="index.html">Home</a>
-<a href="topicals.html"><b>Structure</b></a>
</div>
</table>
<h1 align=center> Using the Meta Object Compiler</h1><br clear="all">
The Meta Object Compiler, moc among friends, is the program which
handles the <a href="metaobjects.html">C++ extensions in Qt.</a>
<p>
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 this
class. Among other things, meta object code is required for the
signal/slot mechanism, runtime type information and the dynamic
property system.
<p>
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' source file).
<p>
Using the moc is introduced in <a href="t7.html">chapter 7</a> of the
Qt Tutorial.  Chapter 7 includes a simple <a href="t7-makefile.html">Makefile that uses the moc</a> and of course source code that
uses signals and slots.
<p>
<h2>Usage</h2>
<p>
The moc is typically used with an input file containing class declarations
like this skeleton:
<p>
<pre>    class MyClass : public QObject
    {
        Q_OBJECT
    public:
        MyClass( <a href="qobject.html">QObject</a> * parent=0, const char * name=0 );
        ~MyClass();

    signals:
        void mySignal();

    public slots:
        void mySlot();

    };
</pre>
<p> In addition to the signals and slots shown above, the moc also
implements object properties as in the next skeleton. 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 property
system.  In this particular case we declare a property of the
enumeration type <code>Priority</code> that is also called "priority" and has a
get function <code>priority()</code> and a set function <code>setPriority().</code>
<p>
<pre>    class MyClass : public QObject
    {
        Q_OBJECT
        Q_PROPERTY( Priority priority READ priority WRITE setPriority )
        Q_ENUMS( Priority )
    public:
        MyClass( <a href="qobject.html">QObject</a> * parent=0, const char * name=0 );
        ~MyClass();

        enum Priority { High, Low, VeryHigh, VeryLow };
        void setPriority( Priority );
        Priority priority() const;
    };
</pre>
<p> Properties can be modified in subclasses with the "Q_OVERRIDE"
macro. The "Q_SETS" macro declares enums to actually be used as
sets. Another macro "Q_CLASSINFO" can be used to attach additional
name/value-pairs to the classes' meta object:
<p>
<pre>    class MyClass : public QObject
    {
        Q_OBJECT
        Q_CLASSINFO( "Author", "Oscar Peterson")
        Q_CLASSINFO( "Status", "Very nice class")
    public:
        MyClass( <a href="qobject.html">QObject</a> * parent=0, const char * name=0 );
        ~MyClass();
    };
</pre>
<p> The three concepts, signals and slots, properties and class
informations, can be combined.
<p>The output produced by the moc must be compiled and linked, just as
the other C++ code of your program; otherwise the building of your
program will fail in the final link phase. By convention, this is done
in one of the following two ways:
<p>
<dl>
<p>
<dt><b>Method A: The class declaration is found in a header
(<var>.h</var>) file</b>
<p>
<dd>If the class declaration above is found in the file
<var>myclass.h</var>, the moc output should be put in a file called
<var>moc_myclass.cpp</var>. This file should then be compiled as
usual, resulting in an object file <var>moc_myclass.o</var> (on Unix)
or <var>moc_myclass.obj</var> (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>
<dt><b>Method B: The class declaration is found in an implementation
(<var>.cpp</var>) file</b>
<p>
<dd>If the class declaration above is found in the file
<var>myclass.cpp</var>, the moc output should be put in a file called
<var>myclass.moc</var>. This file should be #included in the
implementation file, i.e. <var>myclass.cpp</var> should contain the
line<br><var>#include "myclass.moc"</var><br> after the other code. This
will cause the moc-generated code to be compiled and linked together
with the normal class definition in <var>myclass.cpp</var>, so it is
not necessary to compile and link it separately, as in Method A.
<p>
</dl>
<p>Method A is the normal method. Method B can be used in cases where
one for some reason wants 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.
<p>
<h2>Automating moc Usage with Makefiles</h2>
<p>For anything but the simplest test programs, it is recommended to
automate the running of the moc. By adding some rules to the Makefile
of your program, <var>make</var> can take care of running moc when
necessary and handling the moc output.
<p>We recommend using Trolltech's free makefile generation tool
<var>tmake</var> for building your Makefiles. This tool recognizes
both Method A and B style source files, and generates a Makefile that
does all necessary moc handling. tmake is available from <a
href="http://www.trolltech.com/freebies/tmake.html">http://www.trolltech.com/freebies/tmake.html</a>.
<p>If, on the other hand, you want to build your Makefiles yourself,
here are some tips on how to include moc handling.
<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 $&lt; -o $@
</pre>
<p>
<p>
If you want to write portably, you can use individual rules of the
following form:
<p>
<pre>    moc_NAME.cpp: NAME.h
            moc $&lt; -o $@
</pre>
<p>
<p>
You must also remember to add <var>moc_NAME.cpp</var> to your SOURCES
(substitute your favorite name) variable and <var>moc_NAME.o</var> or
<var>moc_NAME.obj</var>to your OBJECTS variable.
<p>
<p>
(While we prefer to name our C++ source files .cpp, the moc doesn't
know that, so you can use .C, .cc, .CC, .cxx or even .c++ if you
prefer.)
<p>
<p>
For Q_OBJECT class declarations in implementation (.cpp) files, we
suggest a makefile rule like this:
<p>
<pre>    NAME.o: NAME.moc

    NAME.moc: NAME.cpp
            moc -i $&lt; -o $@
</pre>
<p>
<p>
This guarantees that make will run the moc before it compiles
<var>NAME.cpp.</var> You can then put
<p>
<pre>    #include "NAME.moc"
</pre>
<p>
at the end of <var>NAME.cpp,</var> where all the classes declared in
that file are fully known.
<p>
<h2>Invoking moc</h2>
<p>
Here are the command-line options supported by the moc:
<p>
<dl>
<dt> -o <var>file</var> <dd> Write output to <var>file</var> rather
than to stdout.
<dt> -f <dd> Force the generation of an #include statement in the
output.  This is the default for files whose name matches the regular
expression \.[hH][^.]* (ie. 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.
<dt> -i <dd> 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.
<dt> -nw <dd> Do not generate any warnings.  Discouraged.
<dt> -ldbg <dd> Write a flood of lex debug information on stdout.
<dt> -p <var>path</var> <dd> Makes the moc prepend <var>path</var>/ to
the file name in the generated #include statement (if one is
generated).
<dt> -q <var>path</var> <dd> Makes the moc prepend <var>path</var>/ to
the file name of qt #include files in the generated code.
</dl>
<p>You can explicitly tell the moc to not 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
<p>
<h2>Diagnostics</h2>
<p>
The moc will warn you about a number of dangerous or illegal
constructs in the Q_OBJECT class declarations.
<p>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 forgot to compile or #include the moc-generated C++ code, or
(in the former case) include that object file in the link command.
<p>
<h2>Limitations</h2>
<p>
The moc does not expand #include or #define, it simply skips any
preprocessor directives it encounters. This is regrettable, but is
normally not a problem in practice.
<p>
The moc 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&lt;int&gt; : public QFrame {
        Q_OBJECT
    [...]
    signals:
        void bugInMocDetected( int );
    };
</pre>
<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>
<h4>Multiple inheritance requires QObject to be first</h4>
<p>
If you are using multiple inheritance, moc assumes that the <em>first</em>
inherited class is a subclass of QObject.  Also, be sure that <em>only</em>
the first inherited class is a QObject.
<p>
<pre>    class SomeClass : public QObject, public OtherClass {
    [...]
    };
</pre>
<p>
(This limitation is almost impossible to remove; since the moc does not expand
is a QObject.)
<p>
<h4>QObject may not be virtually inherited</h4>
<p>
You can not use virtual inheritance in the QObject branch of the
inheritance tree. The following example shows one wrong and one
correct class declaration:
<p>
<pre>    class Wrong : virtual public QObject, virtual public OtherClass {
    [...]
    };

    class Right : public QObject, virtual public OtherClass {
    [...]
    };
</pre>
<p>
<h4>Virtual functions cannot be slots when using multiple inheritance</h4>
<p>
This problem occurs if you are using multiple inheritance. If you
reimplement a virtual function as a slot <strong>and</strong> that
function was originally declared in a class that does not inherit
QObject, your program may crash when a signal triggers the slot.
(This only happens with some compilers.)
<p>
The following example shows one wrong and two correct slot definitions.
<pre>    class BaseClass {
    [...]
        virtual void setValue( int );
    };

    class SubClass : public QObject, public BaseClass {
    [...]
    public slots:
        void setValue( int ); //virtual from BaseClass, error.
        void slotSetValue( int i ) { setValue(i); } //new function, ok.
        void setName( const char* ); // virtual from QObject, ok.
    };
</pre>
<p>
(For those interested in C++ internals: The cause of this problem is
that a slot is internally represented as a function pointer, and
invoked on a QObject pointer. )
<p>
<h4>Function pointers can not be arguments to signals or slots</h4>
<p>
In most cases where you would consider that, 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 (*applyFunction)(<a href="qlist.html">QList</a>*, void*), char*); // illegal
    };
</pre>
<p>
You can work around this restriction like this:
<pre>    typedef void (*ApplyFunctionType)(<a href="qlist.html">QList</a>*, void*);

    class someClass : public QObject {
        Q_OBJECT
    [...]
    public slots:
        void apply( ApplyFunctionType, char *);
    };
</pre>
<p>
<p>
(It may sometimes be even better to replace the function pointer with
inheritance and virtual functions, signals or slots.)
<p>
<h4>Friend declarations can not be placed in signals or slots sections</h4>
<p>
Sometimes it will work, but in general, friend declarations can
not be placed in signals or slots sections.  Put them in the good old
private, protected or public sections instead.  Here is an example of
the illegal syntax:
<p>
<pre>    class someClass : public QObject {
        Q_OBJECT
    [...]
    signals:
        friend class ClassTemplate&lt;char&gt;; // illegal
    };
</pre>
<p>
<h4>Signals and slots cannot be upgraded</h4>
<p>
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:
<p>
<pre>    class Whatever : public QButtonGroup {
    [...]
    public slots:
        void QButtonGroup::buttonPressed; // illegal
    [...]
    };
</pre>
<p>
The QButtonGroup::buttonPressed() slot is protected.
<p>
C++ quiz: What happens if you try to upgrade a protected member
function which is overloaded?
<ol>
<li> All the functions are overloaded.
<li> That is not legal C++.
<!-- C++ ARM, section r.11.3 -->
</ol>
<p>
<h4>Type macros can not be used for signal and slot arguments</h4>
<p>
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:
<p>
<pre>    #ifdef ultrix
    #define SIGNEDNESS(a) unsigned a
    #else
    #define SIGNEDNESS(a) a
    #endif

    class Whatever : public QObject {
    [...]
    signals:
        void someSignal( SIGNEDNESS(a) );
    [...]
    };
</pre>
<p>
A #define without arguments will work as expected.
<p>
<h4>Nested classes cannot be in the signals or slots sections nor have
signals or slots</h4>
<p>
Here's an example:
<p>
<pre>    class A {
        Q_OBJECT
    public:
        class B {
        public slots:   // illegal
            void b();
        [....]
        };
    signals:
        class B {       // illegal
            void b();

        [....]
        }:
    };
</pre>
<p>
<h4>Constructors can not be used in signals or slots sections</h4>
<p>
It is a mystery to me why anyone would put a constructor on
either the signals or slots sections.  You can not, 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:
<p>
<pre>    class SomeClass : public QObject {
        Q_OBJECT
    public slots:
        SomeClass( <a href="qobject.html">QObject</a> *parent, const char *name )
            : <a href="qobject.html">QObject</a>( parent, name ) {}  // illegal
    [...]
    };
</pre>
<p>
<h4>Signals and slots may not have default arguments</h4>
<p>
Since signal->slot binding occurs at run-time, it is
conceptually difficult to use default parameters, which are a
compile-time phenomenon.  This will fail:
<p>
<pre>    class SomeClass : public QObject {
        Q_OBJECT
    public slots:
        void someSlot(int x=100); // illegal
    };
</pre>
<p>
<h4>Signals and slots may not have template arguments</h4>
<p>
Declaring signals and slots with template-type parameters will not
work as expected, even though the moc will not complain. Connecting the
signal to the slot in the following example, the slot will not get
executed when the signal is emitted:
<p>
<pre>   [...]
   public slots:
       void MyWidget::setLocation (pair&lt;int,int&gt; location);

   [...]
   public signals:
       void MyObject::moved (pair&lt;int,int&gt; location);
</pre>
<p>
However, you can work around this limitation by explicitly typedef'ing
the parameter types, like this:
<p>
<pre>   typedef pair&lt;int,int&gt; IntPair;       
   [...]
   public slots:
       void MyWidget::setLocation (IntPair location);

   [...]
   public signals:
       void MyObject::moved (IntPair location);
</pre>
<p>
This will work as expected.
<p>
<h4>Namespace of parent class must be specified even if it is the same as
that of the subclass</h4>
<p>
In the following example, classes x::A and x::B are defined:
<p>
<pre>    namespace x {
        class A : public QObject {
            Q_OBJECT

        public:
            ...
        };
    }

    namespace x {
        class B : public A {
            Q_OBJECT

        public:
            ...
        };
    }
</pre>
<p>
Unfortunately, moc will not understand the
<pre>        class B : public A {
</pre>
<p>
line. You have either to write
<pre>        class B : public x::A {
</pre>
<p>
or define classes A and B in the same namespace block.
<p>
This limitation will disappear with Qt 3.0.
<p>
<h4>Properties need to be declared before the public section that
contains the respective get and set functions</h4>
<p>
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:
<p>
<pre>    class SomeClass : public QObject {
        Q_OBJECT
    public:
    [...]
        Q_PROPERTY( Priority priority READ priority WRITE setPriority ) // illegal
        Q_ENUMS( Priority ) // illegal
        enum Priority { High, Low, VeryHigh, VeryLow };
        void setPriority( Priority );
        Priority priority() const;
    [...]
    };
</pre>
<p>
Work around this limitation by declaring all properties at the
beginning of the class declaration, right after Q_OBJECT:
<p>
<pre>    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;
    [...]
    };
</pre>
<p>

<p><address><hr><div align="center">
<table width="100%" cellspacing="0" border="0"><tr>
<td>Copyright  2001 Trolltech<td><a href="http://www.trolltech.com/trademarks.html">Trademarks</a>
<td align="right"><div align="right">Qt version 2.3.2</div>
</table></div></address></body></html>