Can iterator be checked to be at end of vector?
cornelis van der bent
its vector?
(Background: I know I could compare with myVector.end(), but don't
want to do this. I want to pass two iterators to a method and do some
side by side comparison until one of the iterators is at the end. I
don't want to pass the vectors as well.)
Thanks for listening,
Kees
Victor Bazarov
> Is there a way to ask a vector<Class*>::iterator if it's at the end of
> its vector?
No. An iterator does not know who "its" vector is.
> (Background: I know I could compare with myVector.end(), but don't
> want to do this. I want to pass two iterators to a method and do some
> side by side comparison until one of the iterators is at the end. I
> don't want to pass the vectors as well.)
You need to pass the *ends* [as well], not the vectors.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
cornelis van der bent
> cornelis van der bent wrote:
>
> > Is there a way to ask a vector<Class*>::iterator if it's at the end of
> > its vector?
>
> No. An iterator does not know who "its" vector is.
>
> > (Background: I know I could compare with myVector.end(), but don't
> > want to do this. I want to pass two iterators to a method and do some
> > side by side comparison until one of the iterators is at the end. I
> > don't want to pass the vectors as well.)
>
> You need to pass the *ends* [as well], not the vectors.
>
Thanks!
Is there a meaningful (not technical) reason why an iterator does not
have this information? You write my "its" between ""; is there
perhaps any clue in why you do this, in how you conceptually see an
iterator and "its" container?
Kees
Pascal J. Bourguignon
The end could change.
But you could build smarter iterators, that would include both a
reference to the container and the std::iterator, so you could easily
ask this smart iterator if it's at the end.
--
__Pascal Bourguignon__
Juha Nieminen
> Is there a meaningful (not technical) reason why an iterator does not
> have this information?
I suppose the designers of the language wanted iterators to be as
small as possible and figured that all relevant algorithms could be
implemented without the iterators needing to know the data container
which owns the data they are pointing to, as all the algorithms can be
implemented by making them take iterator pairs (ie. two iterators
specifying a range of values). In fact, most algorithms wouldn't even
benefit from the iterators knowing their parent containers, so this data
would only be useless overhead.
Richard Herring
<nos...@thanks.invalid> writes
>cornelis van der bent wrote:
>> Is there a meaningful (not technical) reason why an iterator does not
>> have this information?
>
> I suppose the designers of the language wanted iterators to be as
>small as possible
I think one motivation was to allow raw pointers to be iterators, so
that standard algorithms could be applied to arrays. If a pointer "is-a"
(in the duck-typing sense) iterator, that puts quite a constraint on
what an iterator can do.
>and figured that all relevant algorithms could be
>implemented without the iterators needing to know the data container
>which owns the data they are pointing to, as all the algorithms can be
>implemented by making them take iterator pairs (ie. two iterators
>specifying a range of values). In fact, most algorithms wouldn't even
>benefit from the iterators knowing their parent containers, so this data
>would only be useless overhead.
--
Richard Herring
Pete Becker
Iterators aren't based on containers. That's looking at it the wrong way
around. Sequences are the fundamental notion in STL. A pair of iterators
specifies a range of objects within a sequence. Containers are one way
to create sequences, but not the only way.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)
Michael Doubez
> cornelis van der bent wrote:
>
>
>
> > On 29 jul, 17:44, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
> >> cornelis van der bent wrote:
>
> >>> Is there a way to ask a vector<Class*>::iterator if it's at the end of
> >>> its vector?
> >> No. An iterator does not know who "its" vector is.
>
> >>> (Background: I know I could compare with myVector.end(), but don't
> >>> want to do this. I want to pass two iterators to a method and do some
> >>> side by side comparison until one of the iterators is at the end. I
> >>> don't want to pass the vectors as well.)
> >> You need to pass the *ends* [as well], not the vectors.
>
> > Thanks!
>
> > Is there a meaningful (not technical) reason why an iterator does not
> > have this information? You write my "its" between ""; is there
> > perhaps any clue in why you do this, in how you conceptually see an
> > iterator and "its" container?
>
> Iterators aren't based on containers. That's looking at it the wrong way
> around. Sequences are the fundamental notion in STL. A pair of iterators
> specifies a range of objects within a sequence. Containers are one way
> to create sequences, but not the only way.
What is misleading is that:
- the Iterator pattern of the GoF book is described as a way "to
access the elements of an aggregate object sequentially"
- the Iterator concept of the STL (SGI) "Iterators are a
generalization of pointers: they are objects that point to other
objects."
In OOP case, it can make sense to keep a reference to the container in
order to stop the iteration ( prev()/next() and done() methods).
--
Michael
James Kanze
> On 30 juil, 14:59, Pete Becker <p...@versatilecoding.com> wrote:
[...]
> > Iterators aren't based on containers. That's looking at it
> > the wrong way around. Sequences are the fundamental notion
> > in STL. A pair of iterators specifies a range of objects
> > within a sequence. Containers are one way to create
> > sequences, but not the only way.
> What is misleading is that:
> - the Iterator pattern of the GoF book is described as a way "to
> access the elements of an aggregate object sequentially"
Which is the most frequent use.
> - the Iterator concept of the STL (SGI) "Iterators are a
> generalization of pointers: they are objects that point to other
> objects."
The problem with the STL here is that they've hijacked the name
of another concept. So whenever you speak about iterators in
C++, you have to say whether you mean what is meant be iterator
in general, or in the context of the standard library.
> In OOP case, it can make sense to keep a reference to the
> container in order to stop the iteration ( prev()/next() and
> done() methods).
Not a reference to the container, but an end iterator. Or use
GoF iterators.
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Pete Becker
Shrug. That doesn't describe STL iterators.
> - the Iterator concept of the STL (SGI) "Iterators are a
> generalization of pointers: they are objects that point to other
> objects."
>
> In OOP case, it can make sense to keep a reference to the container in
> order to stop the iteration ( prev()/next() and done() methods).
C++ is a multi-paradigm language. Applying general OOP principles
(whether valid or not) to try to understand the design of the C++
standard library will often be misleading. In particular, as I said,
iterators are not defined in terms of containers, but in terms of the
abstraction of a sequence.
So "misleading" here seems to mean that applying inapplicable analytic
approaches can lead to incorrect results.
Juha Nieminen
> Iterators aren't based on containers. That's looking at it the wrong way
> around. Sequences are the fundamental notion in STL. A pair of iterators
> specifies a range of objects within a sequence. Containers are one way
> to create sequences, but not the only way.
In fact, there exist iterators which do not point to any data
container at all, such as stream iterators.
Keith H Duggar
STL can been seen as a simple generalization of the above: "a way
to access the elements of a sequence". Notice the change is simply
to remove the "of an aggregate object" specialization. So why is
this misleading? Or do you consider generalization to be generally
(pun:-) misleading?
> - the Iterator concept of the STL (SGI) "Iterators are a
> generalization of pointers: they are objects that point to other
> objects."
>
> In OOP case, it can make sense to keep a reference to the container in
> order to stop the iteration ( prev()/next() and done() methods).
I don't understand what relevance the "OOP case" qualification
has here?
KHD
Jerry Coffin
0516a1...@h11g2000yqb.googlegroups.com>,
kees.van...@gmail.com says...
[ ... ]
> Is there a meaningful (not technical) reason why an iterator does
> not have this information? You write my "its" between ""; is there
> perhaps any clue in why you do this, in how you conceptually see an
> iterator and "its" container?
I'm not sure what "not technical" is supposed to mean here, but the
key reason (IMO, at least) is that an iterator doesn't necessarily
have to be associated with a container at all.
Just for example, consider a random number iterator that you
dereference to generate random (or pseudorandom, as the case may be)
numbers. To get truly random numbers, it might read data from a
thermal diode or a radioactive source. A pseudorandom generator would
invoke its underlying generator for each new number.
OTOH, you could simply treat cases like this as exceptions that would
just have trivial implementations that always said that yes, the
iterator was still "valid".
--
Later,
Jerry.