Well, if foo<bar>(...) starts doing ADL it's going to break a lot of
code. I certainly leave off qualification when using that notation,
knowing that ADL is avoided.
Ok. I see that in c.s.c++ there is a similar response. Revising shared_ptr and intrusive_ptr code I see that all the functions except for cast functions are adequate for ADL (operators + get_pointer()). This is a pity because this makes some pointer-independent code hard in Boost. Interprocess/Shmem uses containers without supposing that allocator::pointer is a raw pointer and it uses static_pointer_cast to construct interprocess::list and interprocess:map classes avoiding template explosion. The current alternative would be: smart_ptr -> get_pointer (ADL) -> raw pointer -> static_cast -> raw_pointer -> smart_ptr(raw_pointer) Currently, I don't see any problem with this in Interprocess (obviously, this can be less efficient than having a specialized static cast function) but I think that we should have a new ADL-friendly cast mechanism in the smart_ptr library to write pointer independent code. These ADL-unfriendly cast functions make boost/pointer_cast.hpp useless in my opinion, as it was thought to be used for pointer independent code via ADL. And the alternatives like target = static_pointer_cast(source, (int*)0); look pretty bad comparing to the original target = static_pointer_cast<int>(source); Regards, Ion