Subject: Re: [boost] [foreach] use of boost_foreach_argument_dependent_lookup_hack
From: Tim Blechmann (tim_at_[hidden])
Date: 2015-07-14 22:30:31
>>>> i've submitted some pull requests about this for several libraries, but
>>>> some devs prefer to blame qt for introducing pseudokeywords instead of
>>>> merging the workarounds
>>> The problem is that blaming Qt puts the burden on their blameless
>>> I'm all for workarounds if they're not overkill.
>> simply blaming qt is much easier than merging a fix :(
>> iirc this fix would be needed by foreach, multiindex and flyweight ...
>> so definitely no overkill that would help a lot of users ...
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk