Mathias Gaunard wrote:
Stewart, Robert wrote:
That would limit ranges because there are ranges that are not pairs of iterators. All ranges can be expressed as pairs of iterators, so I hardly see how that limits anything.
Not true. Some ranges can be generated on the fly based upon a predicate (either provided or built into the range type). Ranges in the Boost.Range library are what you've described, but those in Andrei's scheme are not.
I don't see how your message disproves what I said (nor actually, how it is related at all).
You said all ranges can be expressed as a pair of iterators. I claimed some ranges don't have a predetermined end, so can't be expressed as a pair of iterators. Dave Abrahams correctly noted that it is possible to make an iterator that takes a predicate and, I infer, becomes the end iterator once the range indicated by the predicate has been traversed. Reversing said iterator might be a bit harder. How about another try: traversing a range with changing criteria? A particular range class can take a predicate or some other traversal influencing argument that can change with each advance. How would you express that with iterator pairs?
Boost.Range is just a set of tools to make it more practical to manipulate iterators pairs, which can represent ranges. Alexandrescu offers to ditch iterators and directly define first-class ranges. Yet, in terms of expressiveness, a pair of iterators is not less expressive than Alexandrescu's ranges (discuss below). The only gains there might be are ease-of-defining (but then, if you accept my argument iterators are needed anyway, that gain is moot) and efficiency (which becomes moot too if you allow the two iterators of the pair to be of different types).
Andrei is far better able to defend his notion of Ranges than I, given the time he's spent working on the idea. However, I don't yet accept as axiomatic that all ranges can be expressed as a pair of iterators. The bottom line is if ranges can be made to very reasonably support all use cases, their other benefits (ease of specification, implementation, and composition) make supplanting iterators with ranges highly desirable. Your questions are good, and must be asked before accepting another system that may prove to make certain things impossible rather than simply difficult or awkward. It may be that keeping both is the only viable choice, but that is not nearly as clean and would permit awkward omissions and overlaps, not to mention making education harder still. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.