Custom class QObject inheritance

Maser

Hi,
i was wondering if i have to derive all my custom classes in QT from QObject and use a Q_Object macro, even if im not going to use signal/slots in this class. I think the Q_Objekt makro is not solely for signal/slots Stuff, so do i have to do this, or is it just better to do it?

SGaist

Hi,

If you don't need any features from QObject then there's no need to use QObject as base class at all. Not every class from Qt subclasses QObject. e.g. QVariant or QString are not QObjects.

kshegunov

@Maser
Hello,
I'd say just the opposite. If you are not in need of the meta-object system, which includes signal-slot connections, you're better off not burdening your program with it. There are quite a lot of classes in Qt (most notably the containers) that do not derive from QObject. However, if you wish to create your instances by class name or want to employ the parent-child relationship provided by Qt, then you'll have to derive from QObject. Although the Q_OBJECT macro can be skipped in some cases, I do advise to declare it in all your classes that derive from QObject.

Kind regards.

Maser

I see. So if i kinda want to use new objects on the heap, created in one class, and not break my head deleting it in another one, i have to use parenting system und thus use the QObject inheritance with the Q_OBJECT macro. Ok, thank you.

SGaist

That sounds like a dangerous shortcut to avoid proper memory management. You should take the time to look at the smart pointer classes.

Maser

I thought QT is promoted as a framework, that does the memory management automatically))) But i will look into it, thank you.

SGaist

Qt does help in the management of memory regarding e.g. QObject related stuff (auto-deletion of children objects) or helping writing COW classes, that yes. But it's not a silver bullet that will avoid proper memory management from the programmer.

kshegunov

@Maser said:

I see. So if i kinda want to use new objects on the heap, created in one class, and not break my head deleting it in another one, i have to use parenting system und thus use the QObject inheritance with the Q_OBJECT macro. Ok, thank you.

Hello,
This is not at all what I was trying to communicate. As @SGaist pointed out there is no one size fits all solution, Qt or otherwise. It much depends on your particular case. I will give a brief overview of what I use for what and hopefully this will help you in your quest.

For controller classes, such as thread workers, widget initialization through forms, calculations and the such I derive from QObject, because I need to use the signal-slot mechanism and I'd ideally want to decouple my components. When I need to make sure that I have a valid reference to a QObject that might be destroyed from another part of the program (usually by Qt itself) I use QPointer.

For data classes such as network messages, calculation input/output queued data or other such applications I use implicitly shared objects, which fortunately Qt makes very easy through the QSharedData and QSharedDataPointer classes. If the data payload is very large I switch to explicitly shared objects by means of QExplicitlySharedDataPointer. It breaks reentrancy, but this way I make sure that data copying is not occurring behind the scenes. These also allow me to pass my data classes' instances by value, instead of dragging pointers about my program, which I very much like. Many Qt classes implement implicit sharing: QString, QList, QMap, QImage to name a few.

As for heap management, well I'm a stack man myself, and to be honest I can't seem to remember to have used the QSharedPointer class for anything, but it's there if you wish to make use of it. It does provide external thread-safe reference counting and can be employed to allow you to pass objects around without putting much thought on when they should be deleted.

Sometimes I use QScopedPointer when implementing the PIMPL idiom, but mostly I tend to delete my objects manually. I guess old habits die hard.

All that being said, you can see that there are various solutions to multitude of problems and Qt makes life much easier for many of them. Unfortunately, an universal one doesn't and probably never will exist. I hope this helps you to find an answer after your own hart.

Kind regards.