[Development] check, Mate!

Gábor Lehel illissius at gmail.com
Mon Jan 9 19:37:47 CET 2012


2012/1/9 Gábor Lehel <illissius at gmail.com>:
> 2012/1/9 Stephen Kelly <stephen.kelly at kdab.com>:
>> On Monday, January 09, 2012 18:00:29 Gábor Lehel wrote:
>>
>>> 2012/1/9 Gábor Lehel <illissius at gmail.com>:
>>
>>> > 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 <stephen.kelly at kdab.com> | 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
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>>
>
>
>
> --
> Work is punishment for failing to procrastinate effectively.



-- 
Work is punishment for failing to procrastinate effectively.



More information about the Development mailing list