Qt - Reddit

Why you can't just "forget" raw pointers in Modern C++/Qt (and why smart pointers might crash your app)

Modern C++ (11/14/17/20...) has a very clear mantra: *"Forget* `new` *and* `delete`*, use smart pointers."* It’s excellent advice for pure C++. But the moment you open the Qt documentation, raw pointers (`T*`) start jumping at you from every page.

Why is it that even in 2026, you can't write a serious Qt application using exclusively smart pointers? Let’s look at where "smart" code actually breaks the framework’s logic.

# 1. The Ownership Conflict: Parent-Child vs. Smart Pointers

Qt’s core feature is the **Object Tree**. When you pass a parent to a `QObject` constructor (like a `QWidget`), you are delegating memory management to that parent.

**The "Double Free" Trap:**

Imagine trying to be "modern" and using `std::unique_ptr` (or `QScopedPointer`) where a parent already exists:

void createUI(QWidget* parent) {
// Ownership is passed to parent, BUT unique_ptr also thinks it's the owner
auto label = std::make_unique<QLabel>("Hello", parent);
// ... logic ...
} // unique_ptr goes out of scope and calls delete.

**What goes wrong?**

1. `unique_ptr` honestly deletes the object when the function ends.
2. However, the `parent` still keeps a pointer to this label in its internal `children()` list.
3. When the `parent` is eventually destroyed (e.g., closing the window), it tries to delete the already-deleted label.
4. **Result:** Crash / Double Free.

Smart pointers implement static or reference-counted ownership. They simply aren't aware of `QObject::parent()`.

# 2. The Chaos of GUI Lifecycles and QPointer

In GUI apps, object lifetimes are often unpredictable. A button might be deleted because a tab was closed, a dialog was dismissed, or a server signal was received.

If you need to store a reference to an object you *don't* own:

* `std::shared_ptr` won't help (it will keep the object alive when it should have died).
* `std::weak_ptr` only works with `std::shared_ptr`.

Enter `QPointer<T>`. This is Qt’s unique "weak" pointer. It doesn't own the object, but it **automatically turns to** `null` when the target `QObject` is deleted (via `delete` or by its parent). It does this by subscribing to the `destroyed()` signal. You can't achieve this safety with standard smart pointers without fighting the framework.

# 3. QML and the JavaScript Garbage Collector Trap

If you use QML, the pointer situation gets even weirder. When you pass a `QObject*` from C++ to QML, `QQmlEngine::ObjectOwnership` kicks in.

If a C++ object has no parent (`parent == nullptr`), the JavaScript engine might decide **it** owns the object. When the JS Garbage Collector (GC) sees the object isn't used in QML anymore, it deletes it. Your C++ pointer becomes a dangling "bomb" that will crash your app later. Smart pointers are powerless here; they can't control the JS GC.

# 4. Performance and Low-Level API

When working with `QImage::bits()` or OpenGL contexts, you need raw memory access.

uchar* scanline = image.scanLine(y);
for(int x = 0; x < width; ++x) {
// Direct memory access is the only way to hit 60 FPS
scanline[x] = process(scanline[x]);
}

Any smart pointer overhead inside such loops would kill the performance benefits of C++.

# The "Qt Memory Management" Cheatsheet

To avoid losing your mind between two systems, follow these rules:

1. **Creating a QObject with a Parent?** Use a raw pointer. The parent will handle it. `new QLabel("Text", this)` is perfectly fine.
2. **Creating a QObject WITHOUT a Parent?** Use `std::unique_ptr` or `QScopedPointer`. This prevents leaks.
3. **Need to track an object you don't own?** Use `QPointer`. It’s the only safe way to check if a widget is still alive.
4. **Non-QObject (Business Logic)?** Use `std::unique_ptr` (ownership) or `std::shared_ptr` (shared resources).
5. **Passing objects to QML?** Always set a parent or explicitly call `QQmlEngine::setObjectOwnership(obj, QQmlEngine::CppOwnership)`.
6. **Multi-threading?** Use `QSharedPointer`. It’s

1 view03:32