Can iterator be checked to be at end of vector?

[cornelis van der bent]

Is there a way to ask a vector<Class*>::iterator if it's at the end of
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

 

[cornelis van der bent]

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

 

[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]

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.

 

[Michael Doubez]

cornelis van der bent 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).

 

[James Kanze]

On 30 juil, 14:59, Pete Becker <[email protected]> wrote:

[...]

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.

 

[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]

cornelis van der bent 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"

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]

(e-mail address removed)>,
(e-mail address removed) 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".