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 03:31:39

On Wed, Jul 15, 2015 at 7:28 AM, Gavin Lambert <gavinl_at_[hidden]> wrote:
> On 15/07/2015 16:08, Andrey Semashev wrote:
>>
>> 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.
>
>
> The problem is that if someone has a large existing Qt application that
> actually uses these macros (ie. the program fails to compile if the macros
> are disabled), and then Boost comes along and refuses to compile unless the
> macros are disabled, then it is more likely that the end user will simply
> not use Boost than that they will change their existing code.  Whereas I
> assume that the goal of a library is to encourage people to use it.

Sure, that may be the case. However, I'm still in favor of pushing for
the 'proper' fix on the Qt side, especially since Qt on its own is
moving towards C++11 and general C++ compliance. If that large Qt
application wishes to stay actual, it will have to move on sooner or
later. And from the discussion in Tim's PR[1] it doesn't look like a
difficult change to me.

> Frameworks are bigger than libraries; libraries have to accommodate
> frameworks, rather than the reverse.  And while the user is allowed to
> decide to globally disable the framework's macros or not, a library is not.
> (At least not in public headers; it gets a bit more freedom in compiled
> source, but that's seldom an issue.)

I don't think so. Every library (or framework as a collection of
libraries), no matter how big it is, is a participant in the final
application. If one library defines a macro that can affect other
libraries, then the offender has to be fixed, not the other way
around. It may be hard in practice, like with Qt, but this should be
the general direction of tackling the problem. Qt offers a way to do
this, and IMO, it should be used.

[1] https://github.com/boostorg/foreach/pull/4