The Meta-object Compiler (MOC)

The Meta-object Compiler (MOC)

The meta-object compiler is a program that handles QT's C + + extensions.

The MOC tool reads the C + + header file If it finds one or more of the class declarations that contain the Q_object macro. It is born into a C + + source file that contains the Meta object code. Meta-object code is required for signaling and slot mechanisms, run-time information, and dynamic property systems.

The C + + source files generated by MOC must be compiled and connected during the implementation of the class.

If you create makefiles with Qmake, the included creation rules call the MOC when needed, so you don't have to use the MOC directly.

Usage

MoC typical usage, the input file contains the class declaration:

Class Myclass:publicQobject

{

Q_object

Public

MyClass (qobject*parent =0);

~myclass ();

Signals:

void mysignal ();

Publicslots:

void myslot ();

};

In addition to the signal and slot mechanisms shown above, the MOC implements object properties as shown in the following example. The Q_property () macro declares an object property, and Q_enums () declares an enumeration type in the class that can be used in the property system.

In the following example, we declare an enumeration property, a method that gets the property of the priority () , and a method for setting the property setpriority ():

Qobject

{

Q_object

Q_property (Priority priority-READ priority WRITE setpriority)

Q_enums (priority)

Public

Enum Priority {High, Low, Veryhigh, verylow};

MyClass (qobject *parent =0);

~myclass ();

void setpriority (priority priority) {m_priority = priority;}

Priority priority () const {return m_priority;}

Private

Priority m_priority;

};

The Q_flags () macro declares an enumeration value that can be used as a token. Another macro, Q_classinfo (), allows you to add additional name/value information to the class's meta-object.

Qobject

{

Q_object

Q_classinfo ("Author", "Oscar Peterson")

Q_classinfo ("Status", "Active")

Public

MyClass (qobject *parent =0);

~myclass ();

};

The file generated by the MOC must be compiled and linked in the same way as other C + + source files in the program, otherwise it will fail in the generated link phase. If you use Qmake, this will be done automatically. When Qmake is allowed up, it parses the project's header file and generates a rule to invoke the MOC for those files that contain Q_object macros.

If the class is declared in Myclass.h, the MOC-generated file is moc_myclass.cpp. This file is compiled just like the target file moc_myclass.obj generated on Windows. This target file needs to be connected during the program generation process.

Writing make Rules for invokingMOC

For simple test procedures, it is recommended that the MOC be run automatically. By adding rules to the makefile of the program, you can run the MOC and process the generated files of the MOC as needed.

We recommend that you use the Qmake Makefile build tool to create makefile. This tool generates makefile for all operations required by the MOC.

If you want to create your own makefile, here are some tips on how to include the MOC action.

For the Q_object macro declaration in the header file, if you use only GNU make there is a very useful makefile rule:

Moc_%.cpp:%.h

MOC $ (defines) $ (incpath) $<-o [email protected]

If you want to write more flexibly, you can use the following separate rule format:

Moc_foo.cpp:foo.h

MOC $ (defines) $ (incpath) $<-o [email protected]

You must remember to add Moc_foo.cpp to your SOURCES variable and moc_foo.o or moc_foo.obj to your objects variable.

All examples assume that $ (defines) and $ (incpath) expand to the Define and include path options that are passed to the C + + compiler. These are required by the MOC for preprocessing of the source files.

We like to name the source file. cpp. In fact, you can also use other extensions, such as. C,.cc,.cc,.cxx and. C + +.

For the R q_object Macro declaration in a. cpp file, we recommend that the Makefile rule be as follows:

Foo.o:foo.moc

Foo.moc:foo.cpp

MOC $ (defines) $ (incpath)-I $<-o [email protected]

This ensures that the MOC is allowed before compiling the foo.cpp, and you can put:

#include "Foo.moc"

Put it at the end of the foo.cpp. All class declarations are completely knowable.

Command-Line Options

The following are the MOC Support command-line options:

Option	Description
-o<file>	Write output to <file> rather than to standard output.
-f[<file>]	Force the generation of a #include statement in the output. The default for header files whose extension starts with H or H. This option was useful if you had the header files that does not follow the standard naming conventions. The <file> part is optional.
-I.	Do not generate a #include statement in the output. This is used to run the MOC on a C + + file containing one or more class declarations. You should then #include the Meta-object code in the. cpp file.
-nw	Do not generate any warnings. (not recommended.)
-p<path>	Makes the MOC prepend <path>/to the file name in the generated #include statement.
-i<dir>	Add dir to the include path for header files.
-E	Preprocess only; Do not generate Meta-object code.
-d<macro>[=<def>]	Define macro, with optional definition.
-u<macro>	UNDEFINE macro.
@<file>	Read additional command-line options from <file>. Each line of the file was treated as a single option. Empty lines is ignored. Note that this option isn't supported within the options file itself (i.e. an options file can ' t "include" another file).
-H	Display the usage and the list of options.
-V	Display MOC S version number.
-fdir	Mac OS X. ADD the framework directory dir to the head of the list of directories to is searched for header files. These directories is interleaved with those specified by-i options and is scanned in a left-to-right order Page for GCC). Normally, Use-f/library/frameworks/

You can show that the MOC does not parse some parts of the header file. The MOC defines the preprocessing macro Q_moc_run. 。

The following code will be ignored by MOC.

#ifndef Q_moc_run

...

#endif

Diagnostics

In the Q_object class declaration, the MOC will give some warning of dangerous or illegal creation.

If a connection error occurs during the final phase of the program generation, Yourclass::classname () is said to have no definition or YourClass missing virtual function table vtable. There must have been some errors. Most likely, you forget to compile or #include contain a C + + source file generated by the MOC, or forget to include the destination file in the Connect command. If you use Qmake, try to re-run the update makefile, that's OK.

Limitations

The MOC cannot handle all C + +. The main problem is that the template class cannot use signals or slots. For example:

Class sometemplate<intqframe

{

Q_object

...

Signals:

void mysignal (int);

};

The secondary is that the following structures are illegal. They all choose what we think is better, so removing these restrictions is not a priority for us.

Multipleinheritance Requires Qobject to be first

If multiple inheritance is used, the MOC assumes that the first inherited class is a subclass of Qobject. Ensure that only the first class that is inherited is qobject.

Correct

qobject, public otherclass

{

...

};

Virtual inheritance of Qobject is not supported.

Functionpointers cannot be Signal or Slot Parameters

In most cases, you might consider using a function pointer as a signal or slot parameter, and we feel that inheritance is an alternative to a number. The following examples have syntax errors:

Qobject

{

Q_object

Publicslots:

void apply (voidvoidchar//Wrong

};

We can make the following modifications:

void void *);

Qobject

{

Q_object

Publicslots:

void Char *);

};

It is better to replace the function pointer with an inherited or virtual function.

Enumsand Typedefs must is Fully qualified for Signal and Slot Parameters

When checking the signature of a parameter, Qobject::connect () compares the data type verbatim. As a result, Alignment and qt::alignment are treated as different types. To solve this problem, when declaring signals and slots, or establishing connection, ensure that the data type is fully qualified.

Qobject

{

Q_object

Enum Error {

Connectionrefused,

Remotehostclosed,

Unknownerror

};

Signals:

void statechanged (myclass::error Error);

};

Nestedclasses cannot have signals or Slots

This is an example of a bad structure:

Class A

{

Public

Class B

{

Q_object

Wrong

void B ();

};

};

Signal/slotreturn types cannot be references

The signal and slot can have a return type, but the signal or slot return reference is treated as a return void.

Only signals and Slots could Appear in theSignalsandSlotsSections of AClass

The MOC will complain if you try to place the signal and slot in an unexpected structure on the signal and slot.

http://blog.csdn.net/hai200501019/article/details/9157149

The Meta-object Compiler (MOC)