implementing a new Range
Hi there, 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? Cheers, Alex
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 Basically you need to define range_begin and range_end in the namespace of the object and two traits classes in boost's namespace. -- Anthony Foglia Princeton Consultants (609) 987-8787 x233
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.
On Wed, Aug 26, 2009 at 4:29 PM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
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.
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. Regards, Neil Groves
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?
AMDG Mathias Gaunard wrote:
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?
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) In Christ, Steven Watanabe
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.
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. In Christ, Steven Watanabe
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
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.
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
participants (6)
-
Alex Flint -
Anthony Foglia -
Mathias Gaunard -
Neil Groves -
Steven Watanabe -
Thorsten Ottosen