Am 12.09.2012 um 22:57 schrieb Stephen Kelly <stephen.ke...@kdab.com>:
> On Wednesday, September 12, 2012 19:16:29 Till Oliver Knoll wrote: >> In fact, that is exactly the reason why I thought 'module includes' are such >> a great idea, as to not to forget to write >> >> QT += widgets >> >> Besides, they force me to think twice whether the #include is at the proper >> place (e.g. I would like not to introduce dependencies on any GUI or >> widgets in my "model.dll"). > > Then simply don't use QT += widgets in model.pro. If you accidentally include > <QWidgets/QAction> in a public header of model.dll, you *are* introducing > widgets Well, that's /exactly/ my point ;) By doing "module includes" I instantly realise at the earliest possible stage, "at typing time" (as opposed to compile- or link time), that "Oops! That comes from QtWidgets! That shouldn't be here in my model". (And if it /does/, that's now a good time to think about quickly whether I already have the corresponding entry in QT in my *.pro file) Besides, even if I would want to #include it, that because I'm going to use it within that library (or why else would I include it?). And if I would forget to say QT += widgets in "model.pro", I'd simply get a linker error. Agreed, in that case your "non module include" would have the (slight, IMHO) advantage that you already get informed at compile time. I get informed at link time. By the way, I try to avoid #includes as good as possible in headers: I prefer to use "class forward declarations" where necessary and possible. When my class *uses* a QAction (and I really have to #include) then this is declared in the private class, inside the *.cpp file. That speeds up compilation time and doesn't introduce a dependency for whoever imports my header on QAction (except off course my own class derives from QAction, or QAction is part of the API in form of some parameter etc. - then whoever uses my header needs to know about QAction anyway at some point. But again, I mostly get away with class forward declarations). And I'm not sure what you meant by "mysterious linking error": for me seeing the linker error it was instantly obvious that it was because I was now using "QtWidgets" (the only thing I had to guess was the "module name" for the QT += thing which is (was?) not yet documented in the qmake docs - but I got it right the first time ;)) _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
