Subject: Re: [boost] Boost.Operators issue: polluting namespace of caller through argument-dependent lookup
From: Daniel Frey (d.frey_at_[hidden])
Date: 2016-01-18 14:36:39
> On 18.01.2016, at 20:11, Andrey Semashev <andrey.semashev_at_[hidden]> wrote:
> On 2016-01-18 21:03, Daniel Frey wrote:
>>> On 17.01.2016, at 10:51, John M. Dlugosz <mpbecey7gu_at_[hidden]>
>>> The use of make_shared is finding boost::make_shared as well as
>>> std::make_shared. The program doesn't use boost::shared_ptr and
>>> shouldn't need to know about it.
>> This can not be simply âfixedâ as it is quite an old and established
>> interface. What about the people that actually rely on ADL to kick in
>> to find their unqualified call of make_shared?
> Given that there is BOOST_NO_OPERATORS_IN_NAMESPACE, I don't think that the addition of the boost namespace to ADL was ever intended. I would rather see this fixed and the code that relies on this side effect broken (with the appropriate note in the release notes and the advice to use namespace qualification to resolve the problem).
I think that BOOST_NO_OPERATORS_IN_NAMESPACE is meant to put everything into the global namespace, at least thatâs what the comment in Boost.Operators is saying. This is quite different from putting them into an additional nested namespace (e.g. operator_impl) and adding a âusing namespace operator_impl;â into namespace boost. And from what I remember, this was required as a work-around for bugs in some very old compilers.
That said, I sympathize with fixing the issue when possible. Maybe we could change the default behavior, but offer the old implementation when the user sets BOOST_PLACE_OPERATORS_IN_NAMESPACE_BOOST. And that is only effective when BOOST_NO_OPERATORS_IN_NAMESPACE is *not* used (to avoid breaking the old compilers). Opinions?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk