See the relevant bit from Qt's documentation for more information: http://qt-project.org/doc/qt-5/why-moc.html
See the relevant bit from Qt's documentation for more information: http://qt-project.org/doc/qt-5/why-moc.html
It would be great if we could ditch moc. If you're using Qt without qmake it can be pain in the butt.
For a simple GUI program, in your CMakeLists.txt, you'd typically want something like: set(CMAKE_INCLUDE_CURRENT_DIR ON) set(CMAKE_AUTOMOC ON) find_package(Qt5Core REQUIRED) find_package(Qt5Gui REQUIRED) find_package(Qt5Widgets REQUIRED) qt5_wrap_ui(UI_HEADERS dialog1.ui dialog2.ui mainwindow.ui) qt5_add_resources(UI_RESOURCES resources.qrc) add_executable(simple_program main.cpp dialog1.cpp dialog2.cpp ${UI_HEADERS} ${UI_RESOURCES}) target_link_libraries(simple_program Qt5::Core Qt5::Gui Qt5::Widgets)
Additionally, CMake is the best way I have found to build PyQt5 Python extensions that have C++ Qt bits exposed via PyQt/SIP. A project (of mine) that does this: https://github.com/erikhvatum/RisWidget (MIT license, so feel free to copy and paste anything useful).
Similar things can be used for the various event loops.
If you were so inclined, you could write something that uses less dynamic memory allocation.
Now that I read that code, I think I should be moving some of this stuff to C++11, at least WRT rvalue-refs...
Example: http://code.woboq.org/qt5/qtbase/tests/auto/corelib/kernel/q...
Signals/slots provide a connection abstraction on top of events, and blocking vs queued behavior is a per-connection attribute. So, in cases where the emitter wants to control blocking vs async behavior, you might use the event system with post or send directly.