My article with a draft name "Iterators Must Go (Ahead)" is now published on InformIt and mentioned on reddit.com. Due to the vagaries of posting time and reddit dynamics, the article didn't stay long on reddit's programming page so it got very few views and comments. http://www.reddit.com/r/programming/comments/a2hv3/ Please comment here and/or there and vote up if you liked it. Many thanks to the many Boost participants who reviewed the article prior to publication (see the article's last section for a full list). Andrei
Andrei Alexandrescu wrote:
My article with a draft name "Iterators Must Go (Ahead)" is now published on InformIt and mentioned on reddit.com. Due to the vagaries of posting time and reddit dynamics, the article didn't stay long on reddit's programming page so it got very few views and comments.
Having considered this problem myself, I went down a slightly different path. I was never really comfortable with the idea of "find" and friends returning a range when conceptually, what you're asking for is a location. My solution to that was to introduce a "referent" type that works like a MyType * const (more-or-less). Instead of having something like "Until", I take the referent and use it to split the range into two subranges and then take the piece I care about. Obviously, this has some of the same safety concerns that iterators do, but I'm not sure if it's worth worrying about in practice (especially since there are plenty of ways of invalidating a range to begin with). Still, ranges are pretty useful, and having played around with implementing them, they definitely make it easier to write functions like zip or cartesian_product. - Jim
2009/11/10 James Porter <porterj@alum.rit.edu>
Andrei Alexandrescu wrote:
My article with a draft name "Iterators Must Go (Ahead)" is now published on InformIt and mentioned on reddit.com. Due to the vagaries of posting time and reddit dynamics, the article didn't stay long on reddit's programming page so it got very few views and comments.
Something I have wondered since listening to the lecture (online) from BoostCon, is how the interaction between ranges and containers is designed. For instance, how does std::container<T>::insert and erase look? How would the following example from the SGI STL doc be written in, say, D's standard library (I did search the D documentation, but couldn't find the answer). std::vector<int> v; v.push_back(...); v.erase(v.begin(), std::find(v.begin(), v.end(), X)); Sorry if this is already covered, I would very much be interested in reading further on this topic. Thanks, Christian
2009/11/11 Christian Holmquist <c.holmquist@gmail.com>:
How would the following example from the SGI STL doc be written in, say, D's standard library (I did search the D documentation, but couldn't find the answer).
std::vector<int> v; v.push_back(...); v.erase(v.begin(), std::find(v.begin(), v.end(), X));
That's my biggest complaint with ranges so far. Similar problems exist if you want to get the range of elements before the pivot out of a partition. For this particular case, the usual answer is that you should be using a sentinel-terminated range instead of the find, something like this: auto before_part = before(v.all(), X); But as you point out, it's unreasonable for vector to have to know about a before_range to be able to handle that, so near as I can tell you're stuck with using slice: auto before_part = v.all().slice(0, v.size()-find(v.all(), X).size()); Which is quite ugly and error-prone, not to mention the obvious complaint that it requires a random-access, finite range for something that's doable with just a forward iterator. I've been musing about whether something iterator-like, but opaque, à la fgetpos/fsetpos, would be a feasible solution, but haven't worked out the details. Bright ideas welcome, ~ Scott McMurray
For this particular case, the usual answer is that you should be using a sentinel-terminated range instead of the find, something like this:
auto before_part = before(v.all(), X);
Is vector<T>::erase polymorphic? I assume the following is a valid way to clear a vector v.clear(v.all()); So, what exactly does v.all() return? RandomAccessRange<???>? If so, would the following compile? deque<int> d; vector<int> v; v.clear(d.all()); Here we'd lose some static checks compared to current stl, the above is obviously illegal. Utterly confused, Christian
2009/11/11 Christian Holmquist <c.holmquist@gmail.com>:
So, what exactly does v.all() return? RandomAccessRange<???>? If so, would the following compile?
deque<int> d; vector<int> v; v.clear(d.all());
I figure that v.all() has to return something like a contiguous_range<int>, which internally would be just like a boost-style range<int*>. d.all() would have to return a deque_range, since it needs more intelligence than just ++ing pointers. So no, that wouldn't compile.
participants (4)
-
Andrei Alexandrescu -
Christian Holmquist -
James Porter -
Scott McMurray