On 2016-01-18 22:36, Daniel Frey wrote:
On 18.01.2016, at 20:11, Andrey Semashev
wrote: On 2016-01-18 21:03, Daniel Frey wrote:
On 17.01.2016, at 10:51, John M. Dlugosz
wrote: 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.
The point is that the boost namespace is not guaranteed to be introduced to ADL, so one can't rely on that.
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?
Sounds good to me.