Re: [Boost-users] iterators must go
Date: Wed, 13 May 2009 02:18:07 -0400 From: Scott McMurray <me22.ca+boost@gmail.com> Subject: Re: [Boost-users] iterators must go To: boost-users@lists.boost.org Message-ID: <fa28b9250905122318s3460e1dam5d624160d95ced5@mail.gmail.com> Content-Type: text/plain; charset=UTF-8
On Sun, May 10, 2009 at 09:24, Neal Becker <ndbecker2@gmail.com> wrote:
Interesting presentation:
http://www.boostcon.com/site- media/var/sphene/sphwiki/attachment/2009/05/08/iterators-must-go.pdf
Very persuasive, but it's careful to touch only the examples that look nice. Note, for example, that every range was a whole container.
The three-iterators part was somewhat handwaved-over as well. Take this bit of current code, for example:
auto i = find(c.begin(), c.end(), some_pred()); rotate(c.begin(), i, c.end());
How do you do that nicely with ranges, when he has find returning a range? (Since right now, it implicitly actually returns 2 ranges.)
And how does insertion work? Do we still need to keep the iterators around for insertion position?
I'd love to see the finicky bits worked out, though, since I do like the idea.
~ Scott
Any place you really want a single iterator, a range of one value would work. For appending or streaming out, you really want the concept of an open-ended range. --John TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
On Fri, May 15, 2009 at 8:15 AM, John Dlugosz <JDlugosz@tradestation.com> wrote:
Date: Wed, 13 May 2009 02:18:07 -0400 From: Scott McMurray <me22.ca+boost@gmail.com> Subject: Re: [Boost-users] iterators must go To: boost-users@lists.boost.org Message-ID: <fa28b9250905122318s3460e1dam5d624160d95ced5@mail.gmail.com> Content-Type: text/plain; charset=UTF-8
On Sun, May 10, 2009 at 09:24, Neal Becker <ndbecker2@gmail.com> wrote:
Interesting presentation:
http://www.boostcon.com/site- media/var/sphene/sphwiki/attachment/2009/05/08/iterators-must-go.pdf
Very persuasive, but it's careful to touch only the examples that look nice. Note, for example, that every range was a whole container.
The three-iterators part was somewhat handwaved-over as well. Take this bit of current code, for example:
auto i = find(c.begin(), c.end(), some_pred()); rotate(c.begin(), i, c.end());
How do you do that nicely with ranges, when he has find returning a range? (Since right now, it implicitly actually returns 2 ranges.)
And how does insertion work? Do we still need to keep the iterators around for insertion position?
I'd love to see the finicky bits worked out, though, since I do like the idea.
~ Scott
Any place you really want a single iterator, a range of one value would work. For appending or streaming out, you really want the concept of an open-ended range.
You can shrink ranges from the front or from the back, but you can't grow them. Andrei repeated this several times in his talk so I think it's important. It is part of the improved safety of ranges over iterators. The way I understand this, open-ended ranges don't exist. One way I can think of that fits ranges principles is to use a special insertion range, which has the elements to be inserted and a reference to a container. The range would then call push_back on the container from its pop_front member function. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Fri, May 15, 2009 at 8:15 AM, John Dlugosz <JDlugosz@tradestation.com> wrote:
The three-iterators part was somewhat handwaved-over as well. Take this bit of current code, for example:
auto i = find(c.begin(), c.end(), some_pred()); rotate(c.begin(), i, c.end());
How do you do that nicely with ranges, when he has find returning a range? (Since right now, it implicitly actually returns 2 ranges.)
I don't know what Andrei intended for this case, but here's how I would do it. The BidirectionalRange concept looks something like this:
concept BidirectionalRange<R> : ForwardRange<R> { reference back(R&); const_reference back(const R&); R& pop_back(R&); } (Note: I have no idea how Andrei's concepts look in detail:) Extend this with another function. The nature of bidirectional ranges implies that this can always be supported, I think. R prefix(R full, R suffix); Precondition: suffix is a suffix of full, which means that you can get a range equivalent to suffix by repeatedly calling pop_front(full) Returns: a range r such that chain(r, suffix) is equivalent to full Then your example can be written as: range_t full; range_t suffix = find(full, element); // or find_if(full, some_pred()) rotate(prefix(full, suffix), suffix);
And how does insertion work? Do we still need to keep the iterators around for insertion position?
I think a ranges can be used as insertion positions. The element could be inserted just before or after the start of the range. The details have to be worked out, like if it's before or after, and if it's before, if the range grows to include the element.
Sebastian
I'd love to see the finicky bits worked out, though, since I do like the idea.
~ Scott
Any place you really want a single iterator, a range of one value would work. For appending or streaming out, you really want the concept of an open-ended range.
--John
I fail to see how the use of a Range in place of a Position would "work". It's an abuse of the abstraction. Maybe it's not so much different than using iterators for ranges. Please don't misunderstand. I like the direction that Andrei is going, but I don't believe that getting rid of iterators solves any problems. Both abstractions have their place. How does the D standard library deal with positional insertions in lists and/or vectors? Andrew Sutton andrew.n.sutton@gmail.com
participants (4)
-
Andrew Sutton -
Emil Dotchevski -
John Dlugosz -
Sebastian Redl