|
|
|
@ -1,4 +1,4 @@
|
|
|
|
|
.TH moc 1 "24 June 2001" "Trolltech AS" \" -*- nroff -*-
|
|
|
|
|
.TH tqmoc 1 "24 June 2001" "Trolltech AS" \" -*- nroff -*-
|
|
|
|
|
.\"
|
|
|
|
|
.\" $Id: qt/moc.1 3.3.8 edited Jan 11 14:38 $
|
|
|
|
|
.\"
|
|
|
|
@ -9,28 +9,28 @@
|
|
|
|
|
.\"
|
|
|
|
|
.nh
|
|
|
|
|
.SH NAME
|
|
|
|
|
moc \- generate TQt meta object support code
|
|
|
|
|
tqmoc \- generate TQt meta object support code
|
|
|
|
|
.SH SYNOPSIS
|
|
|
|
|
.B moc
|
|
|
|
|
.B tqmoc
|
|
|
|
|
[-o file] [-i] [-f] [-k] [-ldbg] [-nw] [-p path] [-q path] [-v] file
|
|
|
|
|
.SH DESCRIPTION
|
|
|
|
|
This page documents the
|
|
|
|
|
.B Meta Object Compiler
|
|
|
|
|
for the TQt GUI application framework. The
|
|
|
|
|
.B moc
|
|
|
|
|
.B tqmoc
|
|
|
|
|
reads one or more C++ class declarations from a C++ header or source
|
|
|
|
|
file and generates one C++ source file containing meta object
|
|
|
|
|
information for the classes. The C++ source file generated by the
|
|
|
|
|
.B moc
|
|
|
|
|
.B tqmoc
|
|
|
|
|
must be compiled and linked with the implementation of the class (or it
|
|
|
|
|
can be #included into the class's source file).
|
|
|
|
|
.PP
|
|
|
|
|
If you use
|
|
|
|
|
.B qmake
|
|
|
|
|
.B tqmake
|
|
|
|
|
to create your Makefiles, build rules will be included that call the
|
|
|
|
|
.B moc
|
|
|
|
|
.B tqmoc
|
|
|
|
|
when required, so you will not need to use the
|
|
|
|
|
.B moc
|
|
|
|
|
.B tqmoc
|
|
|
|
|
directly.
|
|
|
|
|
.PP
|
|
|
|
|
In brief, the meta object system is a structure used by TQt (see
|
|
|
|
@ -61,7 +61,7 @@ standard naming conventions.
|
|
|
|
|
.I "-i"
|
|
|
|
|
Do not generate an #include statement in the output. This may be used
|
|
|
|
|
to run
|
|
|
|
|
.B moc
|
|
|
|
|
.B tqmoc
|
|
|
|
|
on a C++ file containing one or more class declarations. You should then
|
|
|
|
|
#include the meta object code in the .cpp file (see USAGE below). If both
|
|
|
|
|
.I -f
|
|
|
|
@ -77,51 +77,51 @@ Write a flood of lex debug information to stdout.
|
|
|
|
|
.TP
|
|
|
|
|
.I "-p path"
|
|
|
|
|
Makes
|
|
|
|
|
.B moc
|
|
|
|
|
.B tqmoc
|
|
|
|
|
prepend
|
|
|
|
|
.IR path /
|
|
|
|
|
to the file name in the generated #include statement (if one is generated).
|
|
|
|
|
.TP
|
|
|
|
|
.I "-q path"
|
|
|
|
|
Makes
|
|
|
|
|
.B moc
|
|
|
|
|
.B tqmoc
|
|
|
|
|
prepend
|
|
|
|
|
.IR path /
|
|
|
|
|
to the file name of qt #include files in the generated code.
|
|
|
|
|
.TP
|
|
|
|
|
.I "-v"
|
|
|
|
|
Displays the version of
|
|
|
|
|
.B moc
|
|
|
|
|
and Qt.
|
|
|
|
|
.B tqmoc
|
|
|
|
|
and TQt.
|
|
|
|
|
.PP
|
|
|
|
|
You can explicitly tell the
|
|
|
|
|
.B moc
|
|
|
|
|
.B tqmoc
|
|
|
|
|
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
|
|
|
|
|
.B moc
|
|
|
|
|
.B tqmoc
|
|
|
|
|
is as if you had removed all lines between a MOC_SKIP_BEGIN and a
|
|
|
|
|
MOC_SKIP_END
|
|
|
|
|
.SH USAGE
|
|
|
|
|
.B moc
|
|
|
|
|
.B tqmoc
|
|
|
|
|
is almost always invoked by
|
|
|
|
|
.BR make (1),
|
|
|
|
|
not by hand.
|
|
|
|
|
.PP
|
|
|
|
|
.B moc
|
|
|
|
|
.B tqmoc
|
|
|
|
|
is typically used with an input file containing class declarations
|
|
|
|
|
like this:
|
|
|
|
|
.PP
|
|
|
|
|
.in +4
|
|
|
|
|
.nf
|
|
|
|
|
class YourClass : public QObject {
|
|
|
|
|
class YourClass : public TQObject {
|
|
|
|
|
TQ_OBJECT
|
|
|
|
|
TQ_PROPERTY( ... )
|
|
|
|
|
TQ_CLASSINFO( ... )
|
|
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
YourClass( QObject * parent=0, const char * name=0 );
|
|
|
|
|
YourClass( TQObject * parent=0, const char * name=0 );
|
|
|
|
|
~YourClass();
|
|
|
|
|
|
|
|
|
|
signals:
|
|
|
|
@ -137,7 +137,7 @@ Here is a useful makefile rule if you only use GNU make:
|
|
|
|
|
.in +4
|
|
|
|
|
.nf
|
|
|
|
|
m%.cpp: %.h
|
|
|
|
|
moc $< -o $@
|
|
|
|
|
tqmoc $< -o $@
|
|
|
|
|
.fi
|
|
|
|
|
.in -4
|
|
|
|
|
.PP
|
|
|
|
@ -147,7 +147,7 @@ following form:
|
|
|
|
|
.in +4
|
|
|
|
|
.nf
|
|
|
|
|
mNAME.cpp: NAME.h
|
|
|
|
|
moc $< -o $@
|
|
|
|
|
tqmoc $< -o $@
|
|
|
|
|
.fi
|
|
|
|
|
.in -4
|
|
|
|
|
.PP
|
|
|
|
@ -158,7 +158,7 @@ to your SOURCES (substitute your favorite name) variable and
|
|
|
|
|
to your OBJECTS variable.
|
|
|
|
|
.PP
|
|
|
|
|
(While we prefer to name our C++ source files .cpp, the
|
|
|
|
|
.B moc
|
|
|
|
|
.B tqmoc
|
|
|
|
|
doesn't know that, so you can use .C, .cc, .CC, .cxx or even .c++ if
|
|
|
|
|
you prefer.)
|
|
|
|
|
.PP
|
|
|
|
@ -170,14 +170,14 @@ a makefile rule like this:
|
|
|
|
|
NAME.o: mNAME.cpp
|
|
|
|
|
|
|
|
|
|
mNAME.cpp: NAME.cpp
|
|
|
|
|
moc -i $< -o $@
|
|
|
|
|
tqmoc -i $< -o $@
|
|
|
|
|
.fi
|
|
|
|
|
.in -4
|
|
|
|
|
.PP
|
|
|
|
|
This guarantees that
|
|
|
|
|
.BR make (1)
|
|
|
|
|
will run the
|
|
|
|
|
.B moc
|
|
|
|
|
.B tqmoc
|
|
|
|
|
before it compiles
|
|
|
|
|
.IR NAME.cpp .
|
|
|
|
|
You can then put
|
|
|
|
@ -192,29 +192,29 @@ where all the classes declared in that file are fully known.
|
|
|
|
|
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
|
|
|
|
|
tqmoc-generated C++ code or include that object file in the link
|
|
|
|
|
command.
|
|
|
|
|
.PP
|
|
|
|
|
The
|
|
|
|
|
.B moc
|
|
|
|
|
.B tqmoc
|
|
|
|
|
will warn you about a number of dangerous or illegal constructs.
|
|
|
|
|
.SH BUGS
|
|
|
|
|
|
|
|
|
|
The
|
|
|
|
|
.B moc
|
|
|
|
|
.B tqmoc
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
The
|
|
|
|
|
.B moc
|
|
|
|
|
.B tqmoc
|
|
|
|
|
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
|
|
|
|
|
.in +4
|
|
|
|
|
.nf
|
|
|
|
|
class SomeTemplate<int> : public QFrame {
|
|
|
|
|
class SomeTemplate<int> : public TQFrame {
|
|
|
|
|
TQ_OBJECT
|
|
|
|
|
....
|
|
|
|
|
signals:
|
|
|
|
@ -226,35 +226,35 @@ signals:
|
|
|
|
|
Less importantly, the following constructs are illegal. All of them
|
|
|
|
|
have have alternatives which we think are usually better, so removing
|
|
|
|
|
these limitations is not a high priority for us.
|
|
|
|
|
.SS "Multiple inheritance requires QObject to be first."
|
|
|
|
|
.SS "Multiple inheritance requires TQObject to be first."
|
|
|
|
|
If you are using multiple inheritance,
|
|
|
|
|
.B moc
|
|
|
|
|
.B tqmoc
|
|
|
|
|
assumes that the
|
|
|
|
|
.B first
|
|
|
|
|
inherited class is a subclass of QObject. Also, be sure that
|
|
|
|
|
inherited class is a subclass of TQObject. Also, be sure that
|
|
|
|
|
.B only
|
|
|
|
|
the first inherited class is a QObject.
|
|
|
|
|
the first inherited class is a TQObject.
|
|
|
|
|
.PP
|
|
|
|
|
.in +4
|
|
|
|
|
.nf
|
|
|
|
|
class SomeClass : public QObject, public OtherClass {
|
|
|
|
|
class SomeClass : public TQObject, public OtherClass {
|
|
|
|
|
...
|
|
|
|
|
};
|
|
|
|
|
.fi
|
|
|
|
|
.in -4
|
|
|
|
|
.PP
|
|
|
|
|
This bug is almost impossible to fix; since the
|
|
|
|
|
.B moc
|
|
|
|
|
.B tqmoc
|
|
|
|
|
does not expand
|
|
|
|
|
#include or #define, it cannot find out which one of the base classes is a
|
|
|
|
|
QObject.
|
|
|
|
|
TQObject.
|
|
|
|
|
.SS "Function pointers cannot 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
|
|
|
|
|
.in +4
|
|
|
|
|
.nf
|
|
|
|
|
class SomeClass : public QObject {
|
|
|
|
|
class SomeClass : public TQObject {
|
|
|
|
|
TQ_OBJECT
|
|
|
|
|
...
|
|
|
|
|
public slots:
|
|
|
|
@ -270,7 +270,7 @@ You can work around this restriction like this:
|
|
|
|
|
.nf
|
|
|
|
|
typedef void (*ApplyFunctionType)( List *, void * );
|
|
|
|
|
|
|
|
|
|
class SomeClass : public QObject {
|
|
|
|
|
class SomeClass : public TQObject {
|
|
|
|
|
TQ_OBJECT
|
|
|
|
|
...
|
|
|
|
|
public slots:
|
|
|
|
@ -295,7 +295,7 @@ sections instead. Here is an example of the illegal syntax:
|
|
|
|
|
.PP
|
|
|
|
|
.in +4
|
|
|
|
|
.nf
|
|
|
|
|
class SomeClass : public QObject {
|
|
|
|
|
class SomeClass : public TQObject {
|
|
|
|
|
TQ_OBJECT
|
|
|
|
|
...
|
|
|
|
|
signals:
|
|
|
|
@ -311,16 +311,16 @@ example:
|
|
|
|
|
.PP
|
|
|
|
|
.in +4
|
|
|
|
|
.nf
|
|
|
|
|
class Whatever : public QButtonGroup {
|
|
|
|
|
class Whatever : public TQButtonGroup {
|
|
|
|
|
...
|
|
|
|
|
public slots:
|
|
|
|
|
QButtonGroup::buttonPressed; // illegal
|
|
|
|
|
TQButtonGroup::buttonPressed; // illegal
|
|
|
|
|
...
|
|
|
|
|
};
|
|
|
|
|
.fi
|
|
|
|
|
.in -4
|
|
|
|
|
.PP
|
|
|
|
|
The QButtonGroup::buttonPressed() slot is protected.
|
|
|
|
|
The TQButtonGroup::buttonPressed() slot is protected.
|
|
|
|
|
.PP
|
|
|
|
|
C++ quiz: What happens if you try to upgrade a protected member
|
|
|
|
|
function which is overloaded?
|
|
|
|
@ -332,7 +332,7 @@ function which is overloaded?
|
|
|
|
|
.SS "Type macros cannot be used for signal and slot arguments"
|
|
|
|
|
|
|
|
|
|
Since the
|
|
|
|
|
.B moc
|
|
|
|
|
.B tqmoc
|
|
|
|
|
does not expand #define, type macros that take an argument
|
|
|
|
|
will not work in signals and slots. Here is an illegal example:
|
|
|
|
|
.PP
|
|
|
|
@ -343,7 +343,7 @@ will not work in signals and slots. Here is an illegal example:
|
|
|
|
|
#else
|
|
|
|
|
#define SIGNEDNESS(a) a
|
|
|
|
|
#endif
|
|
|
|
|
class Whatever : public QObject {
|
|
|
|
|
class Whatever : public TQObject {
|
|
|
|
|
...
|
|
|
|
|
signals:
|
|
|
|
|
void someSignal( SIGNEDNESS(int) ); // illegal
|
|
|
|
@ -388,11 +388,11 @@ sections, where they belong. Here is an example of the illegal syntax:
|
|
|
|
|
.PP
|
|
|
|
|
.in +4
|
|
|
|
|
.nf
|
|
|
|
|
class SomeClass : public QObject {
|
|
|
|
|
class SomeClass : public TQObject {
|
|
|
|
|
TQ_OBJECT
|
|
|
|
|
public slots:
|
|
|
|
|
SomeClass( QObject *parent, const char *name )
|
|
|
|
|
: QObject( parent, name ) {} // illegal
|
|
|
|
|
SomeClass( TQObject *parent, const char *name )
|
|
|
|
|
: TQObject( parent, name ) {} // illegal
|
|
|
|
|
...
|
|
|
|
|
};
|
|
|
|
|
.fi
|
|
|
|
@ -402,14 +402,14 @@ public slots:
|
|
|
|
|
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
|
|
|
|
|
.B moc
|
|
|
|
|
.B tqmoc
|
|
|
|
|
will complain that it can neither
|
|
|
|
|
find the functions nor resolve the type. Here is an example of the
|
|
|
|
|
illegal syntax:
|
|
|
|
|
.PP
|
|
|
|
|
.in +4
|
|
|
|
|
.nf
|
|
|
|
|
class SomeClass : public QObject {
|
|
|
|
|
class SomeClass : public TQObject {
|
|
|
|
|
TQ_OBJECT
|
|
|
|
|
public:
|
|
|
|
|
...
|
|
|
|
@ -429,7 +429,7 @@ beginning of the class declaration, right after TQ_OBJECT:
|
|
|
|
|
.PP
|
|
|
|
|
.in +4
|
|
|
|
|
.nf
|
|
|
|
|
class SomeClass : public QObject {
|
|
|
|
|
class SomeClass : public TQObject {
|
|
|
|
|
TQ_OBJECT
|
|
|
|
|
TQ_PROPERTY( Priority priority READ priority WRITE setPriority )
|
|
|
|
|
TQ_ENUMS( Priority )
|