Rob Stewart <stewart@sig.com> writes:
From: David Abrahams <dave@boost-consulting.com>
Rob Stewart <stewart@sig.com> writes:
I've been thinking about this issue and wonder if the following wouldn't solve the problem neatly for both conforming and non-conforming compilers:
// whatever/foo.h namespace whatever { class foo { ... }; // for conforming compilers unspecified begin(foo const &) { ... }; // for non-conforming compilers namespace boost { namespace range { using whatever::begin; } } // boost/range/begin.hpp namespace boost { inline template <T> unspecified begin(T const & range_i) { using boost::range::begin; return begin(range_i); } }
Careful. Many of the problems you can run into with dispatching onlyshow up in the case where the definition of begin you want to beselected *follows* the template that uses it.
Right. That was the case you'd been discussing and I missed its application here. However, if the author of whatever::foo defines, as a matter of convention or coercion,* begin() in namespace boost::range in the same header as foo, and doesn't invoke it before it's definition, then the problem order won't occur.
Did I miss something?
Two-phase name lookup. 14.6.4 Dependent name resolution [temp.dep.res]
LOL It seems you like quoting that now that you've found it!
It's easy to find when it's in a recent Boost posting :)
I do know about two-phase lookup, but I don't have to deal with it often so I don't always recognize the trouble it can cause a solution like this.
Nevertheless, won't the problem only occur for non-conforming compilers and only when the definition of boost::range::begin(foot const &) is in a separate header
No, it has nothing to do with *definitions* and everything to do with declarations. That function could be defined in a source file.
(provided the author/maintainer of foo follows the prescribed course when it's in the same header)?
No, it will occur anytime boost/range/begin.hpp is included before whatever/foo.h.
Unless you arrange for boost::range to be an associated namespace offoo, you're setting up dangerous #include order dependencies.
Of course.
* It would be documented as the only correct thing to do were this an accepted workaround for non-conforming compilers.
It's not much good if it breaks the conforming compilers. -- Dave Abrahams Boost Consulting www.boost-consulting.com