Every Qt developer knows this moment: everything seems to “work,” but as soon as you add a second base class, forget about inheritance order, or put Q_OBJECT in a .cpp file—the project suddenly turns into a detective mystery with “unresolved external symbols.” Sound familiar?
This chapter carefully transforms chaos into a system: you’ll discover why Qt applications can remain modular even with hundreds of connections, we’ll reveal the practical logic behind MOC’s “magic,” and you’ll learn the secret of how Qt makes connections between objects readable where the callback approach turns code into a macro jungle.
Here you’ll find 3 key pillars of the object model—QObject hierarchies (and why they save memory and nerves), signals/slots (how to “glue” independent components together), and Q_PROPERTY (why properties become a bridge to bindings and tools like Designer). Plus—a “before/after” contrast: old SIGNAL/SLOT vs new Qt6 syntax with compile-time type checking.
Professional developers use this daily—and those who skip the fundamentals typically pay with debugging time and fragile architecture.
This chapter includes ready-to-use code examples.
Chapter Self-Check
Why must the QObject class come first in the list of base classes with multiple inheritance?Answer
Correct answer: MOC (Meta-Object Compiler) must correctly recognize QObject to generate meta-information. If QObject isn’t first, compilation will fail with an error.
Why should objects with a parent be created dynamically via new?Answer
Correct answer: When the parent is destroyed, destructors of all children are automatically called. If an object is created on the stack, attempting to delete it again will lead to a critical error.
What’s the main advantage of the new connect() syntax with function pointers over the old macro-based SIGNAL/SLOT?Answer
Correct answer: Method existence and type compatibility checks happen at compile time rather than runtime, allowing errors to be caught much earlier.
Can you connect a signal with an int parameter to a slot without parameters? And vice versa?Answer
Correct answer: A signal with parameters can be connected to a slot without parameters (the parameter is simply ignored). The reverse is impossible—a slot cannot require more data than the signal provides.
Why does Qt extend C++ with the keywords signals, slots, and emit?Answer
Correct answer: C++ wasn’t designed for GUI programming and doesn’t provide built-in support for an event-driven model. Qt adds this functionality through MOC, making code more readable and object-oriented compared to callback functions.
Why can’t you inherit from multiple classes, each inherited from QObject?Answer
Correct answer: This would lead to duplication of meta-object information and conflicts in the object hierarchy. Only one of the base classes should inherit from QObject.
How does automatic memory management through object hierarchy simplify development?Answer
Correct answer: When a parent object is destroyed, all its children are automatically destroyed recursively. Developers don’t need to manually track and delete child objects, reducing the risk of memory leaks.
What problem do lambda expressions solve, making QSignalMapper practically obsolete?Answer
Correct answer: Lambda expressions allow passing different data to a single slot from different sources directly, without creating an additional mapper object, making code more compact and understandable.
Why is only the READ parameter mandatory when defining a property via Q_PROPERTY?Answer
Correct answer: The minimum requirement for a property is the ability to read it. A property can be read-only (without WRITE), have no notification signal or reset, but a read method must always exist.
When does it make sense to use blockSignals(true)?Answer
Correct answer: When you need to temporarily stop sending signals—for example, when programmatically changing widget values to avoid cascading updates or false triggering of handlers.
Why is it recommended to define a class with the Q_OBJECT macro in a separate .h file rather than in .cpp?Answer
Correct answer: MOC generates additional code for classes with Q_OBJECT. Defining in .cpp can lead to “unresolved external symbol” errors due to how MOC and the build system work.
How does Qt’s signals and slots mechanism surpass callback functions from X Window System and Motif?Answer
Correct answer: Signals and slots provide type checking, full object orientation, component independence, and code readability without using complex macros or binding GUI to business logic.
What is the sender() method used for inside a slot?Answer
Correct answer: The sender() method returns a pointer to the object that sent the signal, allowing a single slot to respond differently to signals from different sources.
Practical Exercises
Easy Level
Counter with Object Hierarchy
Create an application with a Counter class inherited from QObject. The class should have a valueChanged(int) signal and an increment() slot. In main(), create a Counter object, a QPushButton, and a QLabel. When the button is clicked, the counter should increment by 1, and the label should display the current value. Demonstrate automatic memory management by creating objects with a parent.
Hints: Use connect() to link the button’s clicked() signal to the increment() slot. Inside increment(), emit valueChanged(). Connect valueChanged() to the label’s setNum() slot. Create QLabel and QPushButton with a parent so memory is freed automatically.
Medium Level
Editor with Automatic Title Updates
Create a text editor with QTextEdit and a window (QWidget) whose title automatically shows the character count (e.g., “Editor (125 characters)”). Use properties via Q_PROPERTY to store the “document modified” state. Add a button that resets the counter and state. Implement this using modern connect() syntax and lambda expressions.
Hints: Connect QTextEdit’s textChanged() signal to a lambda function that updates the title via setWindowTitle(). Use Q_PROPERTY with READ/WRITE/NOTIFY for the modified property. In the lambda, get the text length via toPlainText().length(). Don’t forget the Q_OBJECT macro in the class header.
Hard Level
Multi-Window Calculator with Signal Overrides
Create a calculator with multiple windows: a main window with a display and separate windows for different button categories (digits, operations, functions). Implement a CalculatorCore class inherited from QObject that knows nothing about GUI but handles calculations via signals and slots. Use findChild() to find buttons by name and meta-object information for dynamic connection creation. Add the ability to temporarily block certain operations via blockSignals().
Hints: Create separate button panel windows with a parent. Use lambda expressions to connect buttons to a single processInput(QString) slot. Apply setObjectName() to buttons to later find them via findChildren(). CalculatorCore can have displayUpdated(QString) and operationCompleted() signals. Use blockSignals() when resetting the calculator. Demonstrate the dumpObjectTree() method for debugging the hierarchy.
💬 Join the Discussion!
Got a handle on Qt’s object model philosophy? Have questions about when to use the new connect() syntax versus the old?
Which approach to memory management resonates with you—automatic via parent-child or manual control? Did you manage to avoid typical mistakes when working with signals and slots?
Share your experience: How easy was the MOC concept to grasp? Have you encountered problems with multiple inheritance? Did the practical exercises help solidify the material?
Your questions and discoveries will help other readers understand this key chapter about Qt’s foundation more deeply!
