> > > <snip, (proposal), replace signals/slots with function-pointer?> > > I hope, this stuff can be better (with a way below we do not need to use > moc, qmake and have an overhead in Qt library)
André already said it (and I agree), but I'll assert clearly: "moc" is a code generator. You get stuff with a code generator that is not possible with function-pointers alone (see below). André respondeth: > There is nothing special about 'slots:' or 'signals:' or even 'emit'. > You don't even need to use them if you don't want to. Use Q_SLOT or > Q_SIGNAL instead if you prefer, and if you want, you can leave out the > emit completely. > Agree. André again:: > 3rd, Qt's signals and slots do a lot more than a vanilla function > pointer will ever do. Or can that transparently handle threading? Queued > connections, blocking if needed? Type safety? Provide information on who > triggered the signal? Work with mis-matched argument lists? Work with > signal-signal connections? Provide many-to-many relationships between > the caller (signal) and the callee (slot)? Signals & slots do provide > all that. > > Other toolkits have also seen all this value, and actually copied the > concept. <snip> Agree again. Many years ago (8+?) I read a blog post that said something to the effect of, "moc is the greatest thing that ever happened to C++". It took me years to understand that at a deeper level. "moc" is a code-generator. Yes, that implies your build process needs to incorporate that step. However, there is nothing wrong with code generation, and it's employed as an adaptive technology to ensure forward-compatibility, promote good design, expand programmer productivity, eliminate user error, and provide for elegant binding across adaptive technologies. "moc" does all these things. Specific real-world examples are found in the features mentioned above by André, but IMHO, that (very good) list leaves out a *lot* more that could have been included. For example, the "dynamic-property/run-time-attribute" discovery/reflection is now possible in C++ because of "moc". It enables the C++ statically-typed (compile-time-typed) language to reflect runtime attributes like you have in Python or Java. That enables whole new programming styles in C++ (e.g., QML property-binding). Regarding, "new programming paradigms", I've read a number of articles related to "C++ scripting" and "Dynamic C++" (do a web search), and those aren't possible without runtime-property-reflection, which is not native to the C++ language. You need a code generator. That's why database interfaces, three-tier/distributed application processing, and many technology interfaces rely upon code-generators (e.g., everything using an "IDL" employs a code-generator). "moc" merely makes that easy with a few macros in C++, not requiring a different file format (e.g., the code generation happens transparently in a build step from your *.hpp/*.cpp files). Similarly, "moc" was a solution to cross-platform coding issues, and it still serves a purpose there. The "moc" code generator can be improved in many ways based on the "meta-object-internals" (and it was for Qt5) without anyone needing to change their C++ code. That is very valuable. Lastly, in case it gets lost in the detail, I want to highlight one item in André's list: The Qt signals/slots as implemented through the moc-code-generator provide a "thread-safe-bridge" between objects in different threads, which are not coupled to each other (e.g., they don't include each other's headers). That is incredibly valuable, and likely not possible without giving up type-safety and other features in a non-code-generator solution, such as through function-pointers and compile-time-template-code-generation. I now very strongly agree with that can't-remember-his-name-blogger-guy from years ago: "I'm a hard-core C++ guy. I don't derive everything from QObject. > However, "moc" is the *best* thing that ever happened to C++." --charley
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
