Re: Andrei's "iterators must go" presentation
on Sat May 30 2009, Dragan Milenkovic <dragan-AT-plusplus.rs> wrote:
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.
Oops. I meant to say that a position can be a concept,
or a part of the interface, or whatever the right term is for
typedef container::position.
(Note to self - don't try to look smart at 4AM).
Yes, it can. But until we have a family of algorithms that uses such an
abstraction, it's "just something you invented."
The use would be to represent a (position of the) single element inside
the container outside of the iteration process. Does this makes sense?
Makes sense, of course. That's what iterators do. But do we need to do
that?
I didn't (yet) come up with a stronger reason why it's a good thing
to have container::position as a requirement.
That's my point.
Of course, I'd define two concepts (Container and
ContainerWithPosition).
Still more complexity.
Among other things said about the range concept, does anyone else
thinks that function 'find' should be renamed to 'reduce_front'
or something similar, since it's misleading?
I still have to think about all this.
In MPL we used drop_front for letting go of the first element of a
range, but for find we just used "find"... since we had iterators ;-)
--
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! ]