moc(1) General Commands Manual moc(1)
NAME
moc - generate Qt meta object support code
SYNOPSIS
moc [-o file] [-i] [-f] [-k] [-ldbg] [-nw] [-p path] [-q path] [-v] file
DESCRIPTION
This page documents the Meta Object Compiler for the Qt GUI application
framework. The moc 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
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 qmake 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.
In brief, the meta object system is a structure used by Qt (see
http://doc.trolltech.com) for component programming and run time type
information. It adds properties and inheritance information to (some)
classes and provides a new type of communication between those instances
of those classes, signal-slot connections.
OPTIONS
-o file
Write output to file rather than to stdout.
-f 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.
-i Do not generate an #include statement in the output. This may be
used to run moc 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 -f and -i are present,
the last one wins.
-nw Do not generate any warnings. Not recommended.
-ldbg Write a flood of lex debug information to stdout.
-p path
Makes moc prepend path/ to the file name in the generated
#include statement (if one is generated).
-q path
Makes moc prepend path/ to the file name of qt #include files in
the generated code.
-v Displays the version of moc and Qt.
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
USAGE
moc is almost always invoked by make(1), not by hand.
moc is typically used with an input file containing class declarations
like this:
class YourClass : public QObject {
Q_OBJECT
Q_PROPERTY( ... )
Q_CLASSINFO( ... )
public:
YourClass( QObject * parent=0, const char * name=0 );
~YourClass();
signals:
public slots:
};
Here is a useful makefile rule if you only use GNU make:
m%.cpp: %.h
moc $< -o $@
If you want to write portably, you can use individual rules of the
following form:
mNAME.cpp: NAME.h
moc $< -o $@
You must also remember to add mNAME.cpp to your SOURCES (substitute your
favorite name) variable and mNAME.o to your OBJECTS variable.
(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.)
If you have class declarations in C++ files, we recommend that you use a
makefile rule like this:
NAME.o: mNAME.cpp
mNAME.cpp: NAME.cpp
moc -i $< -o $@
This guarantees that make(1) will run the moc before it compiles
NAME.cpp. You can then put
#include "nNAME.cpp"
at the end of NAME.cpp, where all the classes declared in that file are
fully known.
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.
The moc will warn you about a number of dangerous or illegal constructs.
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.
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:
class SomeTemplate<int> : public QFrame {
Q_OBJECT
....
signals:
void bugInMocDetected( int );
};
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.
Multiple inheritance requires QObject to be first.
If you are using multiple inheritance, moc assumes that the first
inherited class is a subclass of QObject. Also, be sure that only the
first inherited class is a QObject.
class SomeClass : public QObject, public OtherClass {
...
};
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.
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:
class SomeClass : public QObject {
Q_OBJECT
...
public slots:
// illegal
void apply( void (*apply)(List *, void *), void * );
};
You can work around this restriction like this:
typedef void (*ApplyFunctionType)( List *, void * );
class SomeClass : public QObject {
Q_OBJECT
...
public slots:
void apply( ApplyFunctionType, char * );
};
It may sometimes be even better to replace the function pointer with
inheritance and virtual functions, signals or slots.
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 good old private,
protected or public sections instead. Here is an example of the illegal
syntax:
class SomeClass : public QObject {
Q_OBJECT
...
signals:
friend class ClassTemplate<char>; // illegal
};
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:
class Whatever : public QButtonGroup {
...
public slots:
QButtonGroup::buttonPressed; // illegal
...
};
The QButtonGroup::buttonPressed() slot is protected.
C++ quiz: What happens if you try to upgrade a protected member function
which is overloaded?
- All the functions are upgraded.
- That is not legal C++.
Type macros cannot 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:
#ifdef ultrix
#define SIGNEDNESS(a) unsigned a
#else
#define SIGNEDNESS(a) a
#endif
class Whatever : public QObject {
...
signals:
void someSignal( SIGNEDNESS(int) ); // illegal
};
A #define without arguments works.
Nested classes cannot be in the signals or slots sections nor have signals
or slots
Here's an example:
class A {
Q_OBJECT
public:
class B {
public slots: // illegal
void b();
...
};
signals:
class B { // illegal
void b();
...
}:
};
Constructors cannot be used in signals or slots sections
It is a mystery to us why anyone would put a constructor on 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:
class SomeClass : public QObject {
Q_OBJECT
public slots:
SomeClass( QObject *parent, const char *name )
: QObject( parent, name ) {} // illegal
...
};
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:
class SomeClass : public QObject {
Q_OBJECT
public:
...
// illegal
Q_PROPERTY( Priority priority READ priority WRITE setPriority )
Q_ENUMS( Priority )
enum Priority { High, Low, VeryHigh, VeryLow };
void setPriority( Priority );
Priority priority() const;
...
};
Work around this limitation by declaring all properties at the beginning
of the class declaration, right after Q_OBJECT:
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;
...
};
SEE ALSO
http://www.trolltech.com, C++ ARM, section r.11.3 (for the answer to the
quiz), and http://doc.trolltech.com (for complete Qt documentation).
Trolltech AS 24 June 2001 moc(1)
Generated by dwww version 1.16 on Sat Oct 3 08:33:35 CEST 2026.