"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:
| > 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.
but now you introduce the ADL lookup problem again.
What is "the ADL lookup problem?"
| 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.
How would I traverse a range in that framework?
It depends whether the cursors are homogeneous (like iterators, the usual case) or heterogeneous (a different type at each position). The latter requires a recursive formulation; I won't go into it here because it's not really relevant to what we're discussing. The former looks like: end_cursor<S>::type finish; for (begin_cursor<S>::type p = sequence::begin(s); p != finish; ++p) ... In either case, elements are accessed via: elements_type<S>::type e = sequence::elements(s); // the property map value_type<S>::type v = e(p); // read e(p,v); // write
| 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? ^ ^^^^^^----- redundant ;-)
Only that sequences will be providing begin(s) and not uglified_begin(s). I was going with "uglified" names like sequence_begin() until I thought harder about Thomas' argument and considered the likelihood of bad collisions to be low.
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.
It's related to the argument that you only have to provide one overload of begin/end.
| > |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?
well, for vector<int> v; you can use v.begin() etc. for pair<I,I> p, you can use p.first etc.
And what about a new range type that someone invents? Should they really pick a different interface and not use something like the one Boost.Range already provides for its ranges?
So I don't think that makes much sense; boost.range is a framework---either you use it or you don't.
I repeat, go back and read Peter's posts in http://tinyurl.com/55j7b. The framework ceases to own its concepts eventually. -- Dave Abrahams Boost Consulting www.boost-consulting.com