From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-04-06 05:54:16
"David Abrahams" <dave_at_[hidden]> wrote in message
| "Thorsten Ottosen" <nesotto_at_[hidden]> writes:
| > "Thomas Witt" <witt_at_[hidden]> wrote in message
| > news:d2rt3p$g1b$1_at_sea.gmane.org...
| > | Thorsten Ottosen wrote:
| > | > Dear all,
| > | >
| > | > Have anybody any last objections to breaking changes to boost.range:
| > | >
| > | > boost::range_iterator<T>::type
| > | >
| > | > becomes
| > | >
| > | > boost::range::iterator<T>::type
| > | >
| > | > and so forth. All code that relies on
| > | > ADL inside the range library by overloading the functions begin() etc
| > | > will need to be renamed range_begin() etc.
| > |
| > | Sorry I was unresponsive for a few days but I was travelling. I still
| > | think this is the wrong way to do it. One reason is that it requires
| > | every library X that wants to interface with the range lib to uglify its
| > | interface by the range_ prefix.
| Thomas makes a good point.
hm...I don't think it is particularly ugly compared to so many other hacks.
Once a protocol for ADL hooks are provided, it will seem quite natural
| > yes, but in return the library only has two provide one overload
| > of begin/end.
| Meaning that you don't need a separate overload taking Seq const& just
| to handle mutable rvalues. That's good. However, that benefit
| doesn't depend on uglification. We could use the same old names; the
| interface would just not be useful for mutable rvalues unless the 2nd
| overload were provided.
but now you introduce the ADL lookup problem again.
| Another point is that the whole iterator/const_iterator thing is
| artificial and broken anyway. My work has evolved towards a "cursors
| and property maps" arrangement where cursors encode position/traversal
| and property maps encode access. In that scheme there's no difference
| between the cursors used when traversing constant and mutable
| containers. Of course, if you want to be able to get read access to a
| non-const property map rvalue you may need two overloads for that
How would I traverse a range in that framework?
| We need to decide whether we're going to accept sub-optimal designs or
| not. If we want to use standard iterators (for which there are
| obvious positive arguments) we are forced into some compromises that
| we wouldn't have to accept if using cursors,
How does ADL lookup change in the new framework you're working on?
I don't see how it relates to the the proposed changes to boost.range which
has as its main purpose to enable ADL lookup while using qualified notation.
| > |AFAICS there are two ways out of this
| > |
| > | a) X provides the unprefixed begin as well.
| > how does that solve anything?
| It allows clients of X to use it without boost.range. Go back and
| read Peter Dimov's posts in this thread: http://tinyurl.com/55j7b
| Shouldn't a Boost.Range-conformant range type be usable without the
| dispatching functions in Boost.Range?
well, for vector<int> v; you can use v.begin() etc. for pair<I,I> p, you
can use p.first etc. So I don't think that makes much sense; boost.range
is a framework---either you use it or you don't.
| > | If we want to have adl wrappers
| > what is an ADL wrapper?
| template <class T>
| typename iterator<T>::type
| begin(T& x)
| using somebody's::range_begin;
| return range_begin(x);
| Also known as a dispatching function.
that's what I figured too.