QtObject derived class as class member

Redman

Hello,

I often find myself in a situation like this

class A : public QObject {
Q_OBJECT
public:
.
.
private:
QObjectDerivedClass m_obj1;
}

How should this handled best in qt?

QObjectDerivedClass should be a raw pointer and in its ctor, class A should be set as parent. So when A gets destroyed, QObjectDerivedClass also does?
QObjectDerivedClass should be a QScopedPointer, following the rest as in the previous suggestion
QObjectDerivedClass should be a QSharedPointer, leaving open the possiblity that the QObjectDerivedClass is used in some other context and it doesnt get destroyed if A is destroyed

Christian Ehrlicher

@Redman said in QtObject derived class as class member:

QObjectDerivedClass

What is this class and what should it do? Note: You can't copy classes which derive from QObject.

Redman

@Christian-Ehrlicher The use of that class is specific to class A mostly. It's not some generic QObjectDerivedClass which is needed throughout the application.

Christian Ehrlicher

Then simply use it as value.

SimonSchroeder

Qt is designed around proper OO principles. This means that in theory m_obj1 can be of type QObjectDerivedClass or maybe classes derived from QObjectDerivedClass in the future. It makes the most sense to use a pointer to get proper polymorphism.

One major thing of Qt is that you create objects with a parent. This does not work with objects created on the stack as Qt would still try to call delete on all of its children which will fail for objects allocated on the stack. With Qt you should be using plain pointers (and plain new) for your objects. And always set the parent for objects derived from QObject. Then you also don't need any smart pointer classes.

I've also never use QScopedPointer or QSharedPointer. QScopedPointer hasn't been updated with move semantics. I would rather prefer std::unique_ptr instead. I also don't know if QSharedPointer has any advantages over std::shared_ptr. Wherever it makes sense I personally go for standard C++ instead of Qt. (I never had to use any smart pointer with objects derived from QObject because the parent takes care of this.)

Redman

@SimonSchroeder said in QtObject derived class as class member:

prefer std::unique_ptr instead. I also don't know if QSharedPointer has any advantages over std::shared_ptr. Wherever it makes

So as long as I make sure, that the hierarchy parent child is satisfied I can use raw pointers.
When passing childs to other objects, I can still rely on the parent of child to take care of its deletion.

But what happens if the other objects lives longer than the parent and so child gets deleted while the other objects still acces the child.
Should I work with shared pointers here?

jsulm

@Redman said in QtObject derived class as class member:

Should I work with shared pointers here?

I would say you should rethink your design.
Other objects should not store pointers to children of other objects.
Pass these pointers only when needed to other objects and don't store these pointers there.