Re: [boost] [foreach] use of boost_foreach_argument_dependent_lookup_hack

Subject: Re: [boost] [foreach] use of boost_foreach_argument_dependent_lookup_hack
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-07-15 00:08:42

On 15.07.2015 05:30, Tim Blechmann wrote:
>>
>> I agree that a workaround on our side may seem an easy solution. But in
>> the long term it is a never ending headache. We have a whole winapi
>> submodule for similar reason, and I see Apple macros cause pain here and
>> there from time to time. People just need to learn to stop using such
>> generic macros - the hard way, if needed. I wonder if the problem has
>> been reported to Qt devs and what was the response.
>
> define QT_NO_KEYWORDS. the qt devs are well aware of these issues, but
> of course this will probably *never* be the default, because they
> actually care about backwards compatibility of their APIs and this would
> break zillions of projects.
>
> apple's check macro can also be disabled via
> __ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES, but again: it
> probably won't be defined as default, as it breaks a lot of code, which
> relies on the check macro to be defined. this includes some of apple's
> code like coreaudioutils. apple's developers probably care less about
> API compatibility than qt's devs, though.
>
> so 'learing the hard way' simply won't work here. it is a *constant*
> headache for many developers and a huge waste of time. boost should be
> robust enough to avoid this kind of errors to happen ... and simply
> blaming others code won't help, as maybe you are right, but those others
> may have user code, which depends on these defaults.

If there are config macros to disable the offending macros then that's 
the solution. I realize it's difficult for Qt and Apple to turn them on 
by default but this shouldn't be that hard for their users. And perhaps 
it should be advertised as the recommended way of working with Qt. 
Eventually, this should become headache for Qt devs and those who use 
these macros in API, not for us.