|
|
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.
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).
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.
The moc is typically used with an input file containing class declarations like this skeleton:
class MyClass : public QObject
{
Q_OBJECT
public:
MyClass( QObject * parent=0, const char * name=0 );
~MyClass();
signals:
void mySignal();
public slots:
void mySlot();
};
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 Priority that is also called "priority" and has a
get function priority() and a set function setPriority().
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;
};
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:
class MyClass : public QObject
{
Q_OBJECT
Q_CLASSINFO( "Author", "Oscar Peterson")
Q_CLASSINFO( "Status", "Very nice class")
public:
MyClass( QObject * parent=0, const char * name=0 );
~MyClass();
};
The three concepts, signals and slots, properties and class informations, can be combined.
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:
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.
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, make can take care of running moc when necessary and handling the moc output.
We recommend using Trolltech's free makefile generation tool tmake 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 http://www.trolltech.com/freebies/tmake.html.
If, on the other hand, you want to build 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:
moc_%.cpp: %.h
moc $< -o $@
If you want to write portably, you can use individual rules of the following form:
moc_NAME.cpp: NAME.h
moc $< -o $@
You must also remember to add moc_NAME.cpp to your SOURCES (substitute your favorite name) variable and moc_NAME.o or moc_NAME.objto 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.)
For Q_OBJECT class declarations in implementation (.cpp) files, we suggest a makefile rule like this:
NAME.o: NAME.moc
NAME.moc: NAME.cpp
moc -i $< -o $@
This guarantees that make will run the moc before it compiles NAME.cpp. You can then put
#include "NAME.moc"
at the end of NAME.cpp, where all the classes declared in that file are fully known.
Here are the command-line options supported by the moc:
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
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 forgot to compile or #include the moc-generated C++ code, or (in the former case) include that object file in the link command.
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. 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 workarounds which we think are better alternatives, so removing these limitations is not a high priority for us.
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 limitation is almost impossible to remove; since the moc does not expand is a QObject.)
This problem occurs if you are using multiple inheritance. If you reimplement a virtual function as a slot and 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.)
The following example shows one wrong and two correct slot definitions.
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.
};
(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. )
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:
void apply(void (*applyFunction)(QList*, void*), char*); // illegal
};
You can work around this restriction like this:
typedef void (*ApplyFunctionType)(QList*, 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.)
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:
class someClass : public QObject {
Q_OBJECT
[...]
signals:
friend class ClassTemplate<char>; // illegal
};
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:
void 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?
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(a) );
[...]
};
A #define without arguments will work as expected.
Here's an example:
class A {
Q_OBJECT
public:
class B {
public slots: // illegal
void b();
[....]
};
signals:
class B { // illegal
void b();
[....]
}:
};
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:
class SomeClass : public QObject {
Q_OBJECT
public slots:
SomeClass( QObject *parent, const char *name )
: QObject( parent, name ) {} // illegal
[...]
};
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:
class SomeClass : public QObject {
Q_OBJECT
public slots:
void someSlot(int x=100); // illegal
};
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:
[...]
public slots:
void MyWidget::setLocation (pair<int,int> location);
[...]
public signals:
void MyObject::moved (pair<int,int> location);
However, you can work around this limitation by explicitly typedef'ing the parameter types, like this:
typedef pair<int,int> IntPair;
[...]
public slots:
void MyWidget::setLocation (IntPair location);
[...]
public signals:
void MyObject::moved (IntPair location);
This will work as expected.
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:
[...]
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;
[...]
};
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;
[...]
};
| Copyright © 2000 Trolltech | Trademarks | Qt version 2.2.1
|