Anthony Foglia wrote:

Alex Flint wrote:

...

I'm using a math library that provides a Vector class, but it does not have begin() or end() method, or any other normal container methods. I would like to pass it to functions that take a Range object as a parameter. How can I do this?

I've done this once as an exercise, but not well enough to walk you through it. But the documentation's pretty straightforward, once you find the right section:

http://www.boost.org/doc/libs/1_39_0/libs/range/doc/boost_range.html#method2

I thought you could overload begin/end directly and it would get picked up by ADL, but it looks like it's range_begin/range_end. That really should be changed.

Neil Groves wrote:

I thought you could overload begin/end directly and it would get picked up by ADL, but it looks like it's range_begin/range_end. That really should be changed.

I disagree that this should be changed. This arrangement allows qualified calls to boost::begin(x), boost::end(x) to continue to work and find the approriate range_begin(), range_end() functions via argument dependent lookup. If this rationale does not appear correct, then please explain a little further. I would be happy to make the change if I understand that it really would be an improvement.

The proposed system for C++0x uses directly begin/end as customization points picked up by ADL IIRC. boost::begin could still be used fully qualified and defer to ADL or the basic implemenation, similarly to boost::swap, no?

Steven Watanabe wrote:

...

boost::begin could still be used fully qualified and defer to ADL or the basic implemenation, similarly to boost::swap, no?

If there is no overload of begin, the result may be infinite recursion in some cases instead of a compiler error. (although some compilers will emit a warning)

How so? namespace boost { namespace range_detail { template<typename T> ... begin(const T& t) { return t.begin(); } } template<typename T> ... begin(const T& t) { using range_detail::begin; return begin(t); } } (Needs to replace ... with range_iterator<T> variants, add non-const overloads, handle the old range_begin customization point) I don't see how that kind of thing can cause infinite recursion. If there is no overload of begin picked up by ADL, it uses range_detail::begin.

Steven Watanabe skrev:

AMDG

Mathias Gaunard wrote:

...

namespace boost { namespace range_detail { template<typename T> ... begin(const T& t) { return t.begin(); } }

template<typename T> ... begin(const T& t) { using range_detail::begin; return begin(t); }

}

(Needs to replace ... with range_iterator<T> variants, add non-const overloads, handle the old range_begin customization point) I don't see how that kind of thing can cause infinite recursion. If there is no overload of begin picked up by ADL, it uses range_detail::begin.

I see. I forgot about the default implementation. The problem with this scheme is that if boost is an associated namespace of T, then boost::begin will be ambiguous with boost::range_detail::begin. The workaround used by boost::swap doesn't work in this case.

I had kind of hoped that we could do the same thing as boost.swap. If not, that is really bad news. -Thorsten

AMDG Mathias Gaunard wrote:

Steven Watanabe wrote:

...

I see. I forgot about the default implementation. The problem with this scheme is that if boost is an associated namespace of T, then boost::begin will be ambiguous with boost::range_detail::begin.

A solution could be to have all ranges in the boost namespace overload begin to avoid the ambiguity. Overloading that they already do with the current system.

That isn't enough. std::vector<boost::function<void()> > has boost as an associated namespace e.g.. In Christ, Steven Watanabe