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 users... 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.