Making them all QObject's - good or bad practive?

[andre]

Hello,

in a design for a new application I tend to derive all classes from QObject in order to be able to use the Qt framework to the max. I need to mention that I have developed in Java over the past 10 years where everything derives from 'Object'.

Would somebody consider this a bad practice? I see a lot of benefits: Parent-child, cloning, signals/slots, property support, uniformity, clarity... more?

What are the disadvantages? Are QObjects too heavy-weight?

Any thoughts?
Thanks,
Andre

[wysota]

What are the disadvantages?

You can't make a copy of QObject, that's one thing. So for instance you can't have a list of objects derived from QObject, only a list of pointers to objects derived from QObject.

QList<QObject> bad;
QList<QObject*> good;

QList<QObject> bad;
QList<QObject*> good;

To copy to clipboard, switch view to plain text mode 

[andre]

You can't make a copy of QObject, that's one thing. So for instance you can't have a list of objects derived from QObject, only a list of pointers to objects derived from QObject.

This would fit my approach very well. I will have a coarse grained object structure and each object will have a unique identity, therefore no urgent need to create massive amounts of copies. If I do create copies, I will do that as part of a separate "business transaction" as copies from a resource like a DB or file. The copies would be completely separated by their context.

Is there more to consider? Memory footprint? Creation/destruction complexity? Are those things handled well by Qt?

[wysota]

Memory footprint? Creation/destruction complexity?

It depends if we are talking about hundreds or tens of thousands of such objects. If the former, you are safe.