2012/1/9 Gábor Lehel <[email protected]>: > 2012/1/9 Stephen Kelly <[email protected]>: >> On Monday, January 09, 2012 18:00:29 Gábor Lehel wrote: >> >>> 2012/1/9 Gábor Lehel <[email protected]>: >> >>> > Perhaps we could use GCC's poison pragma[1] to make sure that no one >> >>> > uses them? In some cases it would just be replacing one error message >> >>> > with another (though perhaps a more user-friendly one), but in other >> >>> > cases it would substitute an error for no error. Of course, it only >> >>> > works with GCC. (TBF I haven't checked any other compilers.) >> >>> > >> >>> > [1] http://gcc.gnu.org/onlinedocs/cpp/Pragmas.html >> >>> >> >>> ...though that would also poison them for user code which I'm not sure >> >>> we want, so I suppose you would only want to turn it on when building >> >>> Qt itself. >> >> >> >> I think this is a good idea. It doesn't matter that it only works with GCC. >> If any platform fails, the CI gate does not open for the patch. >> >> >> >> There's a few more instances of 'check' in Qt, after clearing those up, I >> could write a patch to add the pragma to qglobal which user code could >> enable if desired (just like QT_STRICT_ITERATORS or QT_NO_KEYWORDS for >> example). >> >> >> >> #ifdef QT_CHECK_MACRO_CONFLICTS >> >> #pragma GCC poison check <others...> >> >> #endif >> >> >> >> Any suggestions for an alternative name to QT_CHECK_MACRO_CONFLICTS ? Simply >> 'check' perhaps :) ? > > ...one complication is that this will also result in an error when > using the macros _for their intended purpose_. So for the ones which > we legitimately want to use (if any) we might want to only poison them > only on the platforms which _don't_ define them, which would > effectively force them to be ifdeffed to the platforms which do. > > Also, when poisoning an already-defined macro GCC says: > > a.cpp:3: warning: poisoning existing macro "foo" > > I don't know if there's any way to turn it off (doesn't seem to be) or > if it's a problem. > > If it's a problem (and maybe regardless) I guess you'd have to do it like: > > #ifdef QT_POISON_NONPORTABLE_IDENTIFIERS > # ifndef check > # pragma GCC poison check > # endif > # ifndef major > # pragma GCC poison major > # endif > # ... etc. ... > #endif
...and apologies for the email spam but _yet another_ complication is that if the header defining the macro is included later than the one which does the poisoning, that'll also result in an error. Probably that's also solvable by #ifdef QT_CHECK_FOR_IT #include all those headers before poisoning #endif but maybe the whole thing is more trouble than it's worth. > > >> >> >> >> Thanks, >> >> >> >> -- >> >> Stephen Kelly <[email protected]> | Software Engineer >> >> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company >> >> www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 >> >> KDAB - Qt Experts - Platform-Independent Software Solutions >> >> >> _______________________________________________ >> Development mailing list >> [email protected] >> http://lists.qt-project.org/mailman/listinfo/development >> > > > > -- > Work is punishment for failing to procrastinate effectively. -- Work is punishment for failing to procrastinate effectively. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
