katie/src/tools/moc/moc.pod

=head1 NAME

moc - Katie meta object support code generator

=head1 SYNOPSIS

moc [options] <source-file|header-file> [<source-file|header-file>] ...

=head1 DESCRIPTION

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).

=head1 OPTIONS

    -o<file>           write output to file rather than stdout

    -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

    -i                 do not generate an #include statement

    -p<path>           path prefix for included file

    -f[<file>]         force #include, optional file name

    -nn                do not display notes

    -nw                do not display warnings

    @<file>            read additional options from file

    -v                 display version of moc

=head1 EXIT STATUS

moc returns 0 on success and other on unexcepted failure.

=head1 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.

=head2 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.

=head2 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.

=head2 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
        };

=head2 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++.

=head2 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.

=head2  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();
            ...
            }:
        };

=head2 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
            ...
        };

=head2  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;
            ...
        };

=head1 AUTHORS

The Qt Company Ltd.

Copyright (C) 2015 The Qt Company Ltd.
Copyright (C) 2016-2019 Ivailo Monev

Licensed through GNU Lesser General Public License/GNU General Public License.