Home Man
Search
Today's Posts
Register

Linux & Unix Commands - Search Man Pages

CentOS 7.0 - man page for moc (centos section 1)

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)


All times are GMT -4. The time now is 02:48 PM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
UNIX.COM Login
Username:
Password:  
Show Password