Re: [Development] Usage of Q_OBJECT macro in QObject subclasses that don't use signals, slots, or properties
Mitch asked: >> Is this worth mentioning in the documentation? Andre' P replied: > I think it would make sense to list the features that are affected so > that users can decide whether they actually need one of them, or not, > instead of having this unspecific (and untrue) "strange things may > happen". The nearest I can get to thinking of a good reason to leave it unspecific is that it leaves open the possibility that later versions of Qt shall exhibit different strangeness due to a change in Q_OBJECT. This is the usual rationale, for example in a standard, for saying that certain usages may lead to "undefined" behaviour. All the same, the phrasing "strange things may happen" is a red flag - too vague to be useful, so it makes Q_OBJECT sound like magic. Prudent programmers mistrust magic. In the present case, I do think it is worth giving at least some idea of what the problem with omitting Q_OBJECT is. That can be phrased in "undefined behaviour" terms to leave open scope for future changes, as long as it gives the user enough information to make an informed decision. After all, a template class that inherits from a QObject class *can't* (at present) use Q_OBJECT, because moc can't cope with templates, so leaving out Q_OBJECT has to be an option. That means the client code's author needs to understand the pros and cons of that option. So we should at least outline which aspects of such inheritance are likely to violate the principle of least surprise - which of the promises that we make for a QObject-based class depend (or might, in a future release, depend) on it using Q_OBJECT ? Eddy. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Usage of Q_OBJECT macro in QObject subclasses that don't use signals, slots, or properties
On Monday 07 March 2016 20:55:11 Curtis Mitch wrote: > Recently I noticed this sentence in QObject's documentation [1]: > > We strongly recommend the use of this macro in all subclasses of QObject > regardless of whether or not they actually use signals, slots and > properties, since failure to do so may lead certain functions to exhibit > strange behavior. > > Why is this the case? What strange behaviour could result from not doing > so? > > [1] http://doc.qt.io/qt-5/qobject.html#Q_OBJECT Shameless plug: https://marcmutz.wordpress.com/effective-qt/subclassing/ -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Usage of Q_OBJECT macro in QObject subclasses that don't use signals, slots, or properties
On Mon, Mar 07, 2016 at 08:21:54PM +, Curtis Mitch wrote: > Thanks guys. > > Is this worth mentioning in the documentation? I think it would make sense to list the features that are affected so that users can decide whether they actually need one of them, or not, instead of having this unspecific (and untrue) "strange things may happen". Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Usage of Q_OBJECT macro in QObject subclasses that don't use signals, slots, or properties
Op 07/03/2016 om 21:21 schreef Curtis Mitch: Thanks guys. Is this worth mentioning in the documentation? It already says so, right? I don't think it is needed to specify exactly what breaks. André From: Development on behalf of Giuseppe D'Angelo Sent: Monday, 7 March 2016 21:19 To: development@qt-project.org Subject: Re: [Development] Usage of Q_OBJECT macro in QObject subclasses that don't use signals, slots, or properties Il 07/03/2016 20:55, Curtis Mitch ha scritto: Why is this the case? What strange behaviour could result from not doing so? qobject_cast breaks; the meta object system reports and uses the wrong class name (so things like "inherits", "className" etc. don't work); tr() uses the wrong context; and so on. qobject_cast breakage may be serious enough to justify an automatic -1 to all public QObjects-without-Q_OBJECT classes. Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Usage of Q_OBJECT macro in QObject subclasses that don't use signals, slots, or properties
On Mon, Mar 07, 2016 at 07:55:11PM +, Curtis Mitch wrote: > Recently I noticed this sentence in QObject's documentation [1]: > > We strongly recommend the use of this macro in all subclasses of QObject > regardless of whether or > not they actually use signals, slots and properties, since failure to do so > may lead certain > functions to exhibit strange behavior. > > Why is this the case? > What strange behaviour could result from not doing so? Behaviour from not adding Q_OBJECT to classes is well-defined. Whether the result can be considered "strange" is subjective. Documenting behaviour as "strange" is what appears strange to me. IMNSHO the advice to add Q_OBJECT to user code even if not needed is plainly bad as doing so adds compile time and code size overhead. For Qt's own classes it makes sense to a certain degree to e.g. allow qobject_cast in potential user code uniformly. For normal applications *using* Qt that know their needs adding unnecessary Q_OBJECTs is likely to be as beneficial as snake oil. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Usage of Q_OBJECT macro in QObject subclasses that don't use signals, slots, or properties
Thanks guys. Is this worth mentioning in the documentation? From: Development on behalf of Giuseppe D'Angelo Sent: Monday, 7 March 2016 21:19 To: development@qt-project.org Subject: Re: [Development] Usage of Q_OBJECT macro in QObject subclasses that don't use signals, slots, or properties Il 07/03/2016 20:55, Curtis Mitch ha scritto: > Why is this the case? What strange behaviour could result from not doing so? qobject_cast breaks; the meta object system reports and uses the wrong class name (so things like "inherits", "className" etc. don't work); tr() uses the wrong context; and so on. qobject_cast breakage may be serious enough to justify an automatic -1 to all public QObjects-without-Q_OBJECT classes. Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Usage of Q_OBJECT macro in QObject subclasses that don't use signals, slots, or properties
Il 07/03/2016 20:55, Curtis Mitch ha scritto: Why is this the case? What strange behaviour could result from not doing so? qobject_cast breaks; the meta object system reports and uses the wrong class name (so things like "inherits", "className" etc. don't work); tr() uses the wrong context; and so on. qobject_cast breakage may be serious enough to justify an automatic -1 to all public QObjects-without-Q_OBJECT classes. Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Usage of Q_OBJECT macro in QObject subclasses that don't use signals, slots, or properties
Op 07/03/2016 om 20:55 schreef Curtis Mitch: Recently I noticed this sentence in QObject's documentation [1]: We strongly recommend the use of this macro in all subclasses of QObject regardless of whether or not they actually use signals, slots and properties, since failure to do so may lead certain functions to exhibit strange behavior. Why is this the case? What strange behaviour could result from not doing so? [1] http://doc.qt.io/qt-5/qobject.html#Q_OBJECT Functions like QObject::inherits come to mind. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Usage of Q_OBJECT macro in QObject subclasses that don't use signals, slots, or properties
Recently I noticed this sentence in QObject's documentation [1]: We strongly recommend the use of this macro in all subclasses of QObject regardless of whether or not they actually use signals, slots and properties, since failure to do so may lead certain functions to exhibit strange behavior. Why is this the case? What strange behaviour could result from not doing so? [1] http://doc.qt.io/qt-5/qobject.html#Q_OBJECT ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
