"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:
"Thomas Witt" <witt@acm.org> wrote in message news:d2rt3p$g1b$1@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.
yes, but in return the library only has two provide one overload ^^^-"to" 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. 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 purpose. 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, and I think, Thomas, that you'll have to accept that there's not really any completely satisfying solution in C++03.
|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 (http://news.gmane.org/find-root.php?message_id=%3c004801c522aa%24ee97fd10%24...). Shouldn't a Boost.Range-conformant range type be usable without the dispatching functions in Boost.Range?
| b) X requires the use of boost.range in order to have a "natural" interface | | I really think this is bad.
a) or b) ?
I'm pretty sure Thomas means that either one is bad. We aren't left with any good choices.
| 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. -- Dave Abrahams Boost Consulting www.boost-consulting.com