How usable is Qt without its preprocessing step?

Question

I think it's unreasonable for a library to require preprocessing of my source code with a special tool. That said, several people have recommended the Qt library to me for cross platform GUI development.

How usable is Qt without the preprocessing step?

EDIT: Okay people, I'm not meaning this question as a rip on Qt -- too many Qt fanboys are treating it as if it is. I don't want to discuss the merits of the fact that Qt came up with this preprocessing tool. I understand why the tool is there, and I understand why there are large parts of Qt's design that are built upon the idea of preprocessing.

I've never used Qt, ergo I am in no position to rip on it. But I would much rather pay in writing a small amount of boilerplate myself and not depend on ripping apart my entire build process. I won't use Flex and Bison in my current project for the same reason; if I won't use those tools, I'm definitely not going to use another kind of preprocessing.

So, please don't take me as ripping on Qt. I cannot comment on how nice or not nice it is; I have not used it. I just want to know if it is possible to use it without moc.

Answer 1

You can use Qt without the moc, but then you lose certain functions, especially those that make Qt interesting in the first place (such as most of the GUI stuff, signals and slots, and string translation). But it's still a nice general purpose library, even without moc.

Answer 2

Qt doesn't require the use of moc just to use it, it requires that usage if you create a subclass of QObject, and to declare signals and slots in your custom classes.

It's not unreasonable, moc provides features that C++ doesn't have, signals/slots, introspection, etc.

So, to do something minimally advanced, you WILL have to use the moc preprocessor. You either love it, or hate it.

Answer 3

I don't consider it unreasonable that Qt requires a special pre-processing tool, considering how large and comprehensive of a library it is.

Other similarly comprehensive libraries such as Boost and GLib don't require special pre-processing tools but do make extensive use of the standard C preprocessor. Qt could have been implemented using only the C preprocessor, but by using its own special preprocessing tool, it can provide a cleaner syntax and avoid many of the pitfalls associated with C preprocessor macros.

As has been answered already, though, you can use Qt without moc, just not anything that requires signals and slots. Yes, this does include all of the GUI stuff, but Qt is not by any means just a GUI library.

Answer 4

I have a solution, that is not super-clean and not 100% satisfactory, but that allows to connect Qt signals to your own code without having to use the MOC compiler (I had exactly the same constraint as in the question, i.e. not able to run the MOC compiler in the building process of my application).

To be able to capture Qt signals without using MOC, I am using the following tricks:

(1) get the definition of QMetaCallEvent (copy it from ): In Qt 5.x, you will have something like:

class QMetaCallEvent : public QEvent {
public:
    inline int id() const {
        return method_offset_ + method_relative_;
    }

    virtual void placeMetaCall(QObject *object);

private:
    QMetaCallEvent();
    void* slotObj_;
    const QObject *sender_;
    int signalId_;
    int nargs_;
    int *types_;
    void **args_;
    void *semaphore_;
    void *callFunction_;
    ushort method_offset_;
    ushort method_relative_;
};

(2) In your widget class that needs to capture Qt signals, you will inherit from a Qt widget (say QButton), and define the following function:

// Inspired by QObject::connect() in src/corelib/kernel/qobject.cpp
bool connect_sender(
    const QObject* sender, const char* signal, int method_index
) {

        // We need to generate MetaCall events (since QObject::event()
        //   is the only virtual function we can overload)
        // (note that the other connection types do not generate events).
        Qt::ConnectionType type = Qt::QueuedConnection ;

        if(sender == 0 || signal == 0) {
            std::cerr << "null sender or signal" << std::endl ;
            return false ;
        }

        QByteArray tmp_signal_name;
        const QMetaObject *smeta = sender->metaObject();
        ++signal; //skip code
        int signal_index = smeta->indexOfSignal(signal);
        if (signal_index < 0) {
            // check for normalized signatures
            tmp_signal_name = 
                QMetaObject::normalizedSignature(signal).prepend(*(signal - 1));
            signal = tmp_signal_name.constData() + 1;
            signal_index = smeta->indexOfSignal(signal);
            if (signal_index < 0) {
                std::cerr << "Signal \'" << signal << "\' not found" 
                          << std::endl ;
                return false;
            }
        }

        int *types = 0;

        QMetaObject::connect(
            sender, signal_index, this, method_index, type, types
        ) ;

        return true ;
    }

(3) overload the event() function:

bool event(QEvent* e) {
    if(e->type() == QEvent::MetaCall) {
        QMetaCallEvent* ev = static_cast<QMetaCallEvent*>(e);
        switch(ev->id()) {
            // insert your handling code here
        }  
        return true;
    }
    return QObject::event(e) ;
}

Now, if you call connect_sender(qobject, signal_name, method_index), this will call event() each time the signal is fired, with the specified method_index retrieved in ev->id().

Important note: I have been using this trick in my application for several years, it works quite well, but it is not very clean. One of the consequences is that whenever the definition of QMetaCallEvent changes, you need to edit your declaration accordingly (unfortunately it is not exposed in the header files of Qt).

Answer 5

I don't have a full answer, but as I understand it, moc mainly (or perhaps only) generates additional C++ code. So potentially there's nothing it does that you couldn't also do yourself manually. However, I have no idea how tedious that might be nor how much study it might take to understand all the necessary concepts and details that go into that code.

---

Also, as I side note: In my opinion, the reason you're getting as much defense of Qt and moc is because you started your question with the strongly worded "I think it's unreasonable" which is easily interpreted to mean that you don't think moc should ever have existed. This distracts from your actual question. I think it would have been better just to say "moc doesn't fit into my build system" or simply "I have my own reasons for not wanting to use it".

Answer 6

It's completely usable now. The maintainer of moc has made an alternative with slightly more verbose syntax than ordinary Qt, but it uses standard C++14 so there's no extra step.

It's called 'Verdigris'

(as an aside, moc isn't really a preprocessing step so much as a code generator. The code you write is valid C++, and moc doesn't change any of it. It just generates extra C++ code for you.)