moc.1

tmark1.11:用于生成QT/EMBEDDED应用工程的Markfile文件

.TH Moc 3qt "9 July 1999" "Troll Tech AS" \" -*- nroff -*-
.\" Copyright 1992-1999 Troll Tech AS.  All rights reserved.  See the
.\" license file included in the distribution for a complete license
.\" statement.
.\"
.ad l
.nh
.SH NAME
Moc \- Using the meta object compiler.
.PP
The Meta Object Compiler, moc among friends, is the program which handles the C++ extensions in Qt.
.PP
The moc reads a class declaration and produces a C++ source file containing the names of all signals and slots for that class (and a little more). This C++ source file the moc outputs must be compiled and linked with the implementation of the class (or it can be #included into the source file).
.PP
Using the moc is introduced in chapter 7 of the Qt Tutorial. Chapter 7 includes a simple Makefile that uses the moc and of course source code that uses signals and slots.
.PP
.SS "Invoking moc"
Here are the command-line options supported by the moc:
.IP "-o \fIfile\fR" 1c
Write output to \fIfile\fR rather than to stdout.
.IP "-f" 1c
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.
.IP "-i" 1c
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.
.IP "-nw" 1c
Do not generate any warnings. Discouraged.
.IP "-ldbg" 1c
Write a flood of lex debug information on stdout.
.IP "-dbg" 1c
Treat all non-signal members as slots, for internal debugging purposes. This is not useful for programming Qt clients.
.IP "-p \fIpath\fR" 1c
Makes the moc prepend \fIpath\fR/ to the file name in the generated #include statement (if one is generated).
.IP "-q \fIpath\fR" 1c
Makes the moc prepend \fIpath\fR/ to the file name of qt #include files in the generated code.
.PP
.SS "Usage"
moc is almost always invoked by make(1), not by hand.
.PP
moc is typically used with an input file containing class declarations like this skeleton:
.PP
.nf
.br
    class YourClass : public QObject {
.br
        Q_OBJECT
.br
    public:
.br
        YourClass( QObject * parent=0,
.br
                              const char * name=0 );
.br
        ~YourClass();
.br
.br
    signals:
.br
.br
    public slots:
.br
.br
    };
.fi
.PP
Here is a useful makefile rule if you only use GNU make:
.PP
.nf
.br
    m%.cpp: %.h
.br
            moc $< -o $@
.fi
.PP
If you want to write portably, you can use individual rules of the following form:
.PP
.nf
.br
    mNAME.cpp: NAME.h
.br
            moc $< -o $@
.fi
.PP
You must also remember to add \fImNAME.cpp\fR to your SOURCES (substitute your favorite name) variable and \fImNAME.o\fR to your OBJECTS variable.
.PP
(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.)
.PP
If you have class declarations in C++ files, we recommend that you use a makefile rule like this:
.PP
.nf
.br
    NAME.o: mNAME.cpp
.br
.br
    mNAME.cpp: NAME.cpp
.br
            moc -i $< -o $@
.fi
.PP
This guarantees that make(1) will run the moc before it compiles \fINAME.cpp.\fR You can then put
.PP
.nf
.br
    #include "nNAME.cpp"
.fi
.PP
at the end of \fINAME.cpp,\fR where all the classes declared in that file are fully known.
.PP
You can explicitely 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
.PP
.SS "Diagnostics"
Sometimes you may get linkage errors, saying that YourClass::className() is undefined or that YourClass lacks a vtbl. Those errors happen most often when you forget to compile the moc-generated C++ code or include that object file in the link command.
.PP
The moc will warn you about a number of dangerous or illegal constructs.
.PP
.SS "Bugs"
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.
.PP
The moc does not handle all of C++. The main problem is that class templates cannot have signals or slots. This is an important bug. Here is an example:
.PP
.nf
.br
    class SomeTemplate<int> : public QFrame {
.br
        Q_OBJECT
.br
    [...]
.br
    signals:
.br
        void bugInMocDetected( int );
.br
    };
.fi
.PP
Less importantly, the following constructs are illegal. All of them have workarounds which we think are better alternatives, so fixing these bugs is not a high priority for us.
.SH "Multiple inheritance requires QObject to be first"
If you are using multiple inheritance, moc assumes that the \fIfirst\fR inherited class is a subclass of QObject. Also, be sure that \fIonly\fR the first inherited class is a QObject.
.PP
.nf
.br
    class SomeClass : public QObject, public OtherClass {
.br
    [...]
.br
    };
.fi
.PP
This bug is almost impossible to fix; since the moc does not expand #include or #define, it cannot find out which one of the base classes is a QObject.
.SH "Virtual functions cannot be slots when using multiple inheritance"
This problem occurs if you are using multiple inheritance. If you reimplement a virtual function as a slot \fBand\fR that function was originally declared in a class that does not inherit QObject, your program will crash when a signal triggers the slot. (This may not happen on all platforms.)
.PP
The following example shows one wrong and two correct slot definitions.
.PP
.nf
.br
    class BaseClass {
.br
    [...]
.br
        virtual void setValue( int );
.br
    };
.br
.br
    class SubClass : public QObject, public BaseClass {
.br
    [...]
.br
    public slots:
.br
        void setValue( int ); //virtual from BaseClass, error.
.br
        void slotSetValue( int i ) { setValue(i); } //new function, ok.
.br
        void setName( const char* ); // virtual from QObject, ok.
.br
    };
.fi
.PP
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.
.SH "Function pointers can not be arguments to signals or slots"
In most cases where you would consider that, we think inheritance is a better alternative. Here is an example of illegal syntax:
.PP
.nf
.br
    class someClass : public QObject {
.br
        Q_OBJECT
.br
    [...]
.br
    public slots:
.br
        void apply(void (*applyFunction)(QList*, void*), char*);
.br
    };
.fi
.PP
You can work around this restriction like this:
.PP
.nf
.br
    typedef void (*ApplyFunctionType)(QList*, void*);
.br
.br
    class someClass : public QObject {
.br
        Q_OBJECT
.br
    [...]
.br
    public slots:
.br
        void apply( ApplyFunctionType, char *);
.br
    };
.fi
.PP
(It may sometimes be even better to replace the function pointer with inheritance and virtual functions, signals or slots.)
.SH "Friend declarations can not be placed in signals or slots sections"
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:
.PP
.nf
.br
    class someClass : public QObject {
.br
        Q_OBJECT
.br
    [...]
.br
    signals:
.br
        friend class ClassTemplate<char>;
.br
    };
.fi
.SH "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:
.PP
.nf
.br
    class Whatever : public QButtonGroup {
.br
    [...]
.br
    public slots:
.br
        void QButtonGroup::buttonPressed;
.br
    [...]
.br
    };
.fi
.PP
The QButtonGroup::buttonPressed() slot is protected.
.PP
C++ quiz: What happens if you try to upgrade a protected member function which is overloaded?
.IP 1
All the functions are overloaded.
.IP 2
That is not legal C++. <!-- C++ ARM, section r.11.3 -->
.SH "Type macros can not be used for signal and slot arguments"
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:
.PP
.nf
.br
    #ifdef ultrix
.br
    #define SIGNEDNESS(a) unsigned a
.br
    #else
.br
    #define SIGNEDNESS(a) a
.br
    #endif
.br
.br
    class Whatever : public QObject {
.br
    [...]
.br
    signals:
.br
        void someSignal( SIGNEDNESS(a) );
.br
    [...]
.br
    };
.fi
.PP
A #define without arguments works.
.SH "Nested classes cannot be in the signals or slots sections nor have
signals or slots" Here's an example:
.PP
.nf
.br
    class A {
.br
        Q_OBJECT
.br
    public:
.br
        class B {
.br
        public slots:
.br
            void b();       // Nested class with slot
.br
        [....]
.br
        };
.br
    signals:
.br
        class B {
.br
            void b();       // Nested class in signals:
.br
.br
        [....]
.br
        }:
.br
    };
.fi
.SH "Constructors can not be used in signals or slots sections"
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:
.PP
.nf
.br
    class SomeClass : public QObject {
.br
        Q_OBJECT
.br
    public slots:
.br
        SomeClass( QObject *parent, const char *name )
.br
            : QObject( parent, name ) {}
.br
    [...]
.br
    };
.fi
.SH "Signals and slots may not have default arguments"
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:
.PP
.nf
.br
    class SomeClass : public QObject {
.br
        Q_OBJECT
.br
    public slots:
.br
        void someSlot(int x=100);
.br
    };
.fi
.SH "Signals and slots may not have template arguments"
Declaring signals and slots with template-type parameters will not work as expected, even though the moc will accept it. Connecting the signal to the slot in the following example, the slot will not get executed when the signal is emitted:
.PP
.nf
.br
   [...]
.br
   public slots:
.br
       void MyWidget::setLocation (pair<int,int> location);
.br
.br
   [...]
.br
   public signals:
.br
       void MyObject::moved (pair<int,int> location);
.fi
.PP
However, you can work around this limitation by explicitly typedef'ing the parameter types, like this:
.PP
.nf
.br
   typedef pair<int,int> IntPair;
.br
.br
   [...]
.br
   public slots:
.br
       void MyWidget::setLocation (IntPair location);
.br
.br
   [...]
.br
   public signals:
.br
       void MyObject::moved (IntPair location);
.fi
.PP
This will work as expected.
.PP
.SH "SEE ALSO"
.BR http://www.troll.no/qt/moc.html
.SH COPYRIGHT
Copyright 1992-1999 Troll Tech AS.  See the license file included in
the distribution for a complete license statement.
.SH AUTHOR
Generated automatically from the source code.