Here's the problem I ran into
http://stackoverflow.com/questions/34449254/how-is-argument-dependent-lookup...
|usingstd::tr1::shared_ptr; ||usingstd::tr1::make_shared;|
|shared_ptr<Dog>Gamma::knockout (constHotel&target){Eggsoftboiled
(target.ID);softboiled.sequence
^=0x40000000;returnmake_shared<Dog>(softboiled,target.kin,Frank::myself());} |
The arguments to the constructor passed through make_shared are of types
|Able::Bravo::Charlie::Egg&,constuint32_t&,constFrank&|
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.
It turns out that Frank is derived privately from boost::totally_ordered1 (and and Egg
from boost::totally ordered).
Some Boost header that's being used in this translation unit just happens to pull in
Boost's shared_ptr stuff. It ends up effectively polluting the namespace of possible
calls involving these types, thanks to argument-dependent lookup.
Furthermore, which Boost headers include which will change from version to version. I
have this problem show up much more in Boost 1.60 than I have in Boost 1.59. There is no
easy way around it beyond qualifying the call make_shared, and I specifically want to
avoid that so I don't litter the program with tr1's (this varies by compiler and version
as to whether tr1 is required, prohibited, or optional, so I want it in one place.)
I believe the proper thing to do, which is a very simple fix actually, is to define the
mix-in classes like totally_ordered (and other things from Boost.Operators in particular)
in a unique inner namespace, and then make aliases in the boost namespace where they are
published as being found.
namespace boost {
*namespace inner_name_1 { *
template