Re: Andrei's "iterators must go" presentation
on Thu May 28 2009, Dragan Milenkovic <dragan-AT-plusplus.rs> wrote:
David Abrahams wrote:
on Wed May 27 2009, Dragan Milenkovic <dragan-AT-plusplus.rs> wrote:
Dave Abrahams wrote:
on Tue May 12 2009, Dragan Milenkovic <dragan-AT-plusplus.rs> wrote:
Andrei Alexandrescu wrote:
Mathias Gaunard wrote:
"Iterators can't implement it!", slide 52, about range adaptor
Stride.
Iterators have trouble implementing strides because they don't
intrinsically
know
their limits. That's why an iterator could implement a stride by
essentially
defining a mechanism to figure out whether it's safe to take a step.
Such a
mechanism makes the iterator essentially a range underneath.
So maybe some iterators are ranges underneath, but in order to kill'em
I guess all or most of iterators should have to be ranges underneath.
OTOH, all ranges are iterators underneath.
Even input streams?
Actually, I've changed my view on the problem (once I gave it a bit
thought). Getting rid of iterators now seems like a good thing,
but there has to be another level of abstraction, lower than a range.
It's for those who are not writing a generic, but a specific algorithm.
If it's not generic, maybe you don't mean abstraction... you can use
pointers, or integers, or whatever is appropriate to the specific data
structure. Or am I misunderstanding what you mean by "specific?"
Maybe you should check my post where I first changed my mind in favor
of eliminating iterators. I know it's a bit of mess... I simply stated
my thoughts about how to handle the issue.
Pointers are no good, you cannot erase an element with it.
Depends on the container. It certainly works for vectors. But then
again, in the domain of the STL algorithms there's no erasing anything
anyway.
Keys would make the interface a Java-like.
Hmm? Java iterators are essentially "input ranges" IIUC. How do keys
come into it?
A position _can_ be abstract, so why not. Like an iterator after a
diet.
Because abstraction is only helpful inasmuch as it fits into a generic
(meant in the "generic" sense -- think polymorphism) context. If you
don't have a use for a given abstraction, it adds nothing but
complexity. And complexity hurts.
About input streams... I'm not sure what you mean. An input range?
Isn't this equivalent to two input iterators? Of course, an input
range is more efficient and more intuitive.
That's my point. While an input range *can* be represented by two
iterators, it's by no means clear that an input range is "input
iterators underneath."
I wrote this a relatively long time ago. I think it makes more sense
if you don't use "underneath" to mean "representation", but "the
same functionality"... but don't take my word on it.
I guess I thought the argument was that some iterators, for example
for strides, need more knowledge about the container and this gives
them the same functionality as a range.
That is true.
I responded that although this is true, it's not a real argument that
(all) iterators can be eliminated.
Also true.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]