Using iterator as a parameter

[mike3]

Hi.

I was wondering if this was a good or bad idea. I was trying to
program a "container" object which has iterators, and was thinking of
having member functions that take as parameters iterators into that
container. Is that a good or bad idea? Because it is possible to pass
an iterator to the wrong container. But I noticed that in standard
containers there is this kind of thing (like vector::erase).

 

[Marcel Müller]

I was wondering if this was a good or bad idea. I was trying to
program a "container" object which has iterators, and was thinking of
having member functions that take as parameters iterators into that
container. Is that a good or bad idea?

I see nothing wrong with that. It is a common practice.
Iterators should by definition be cheap to copy. So passing them by
value is no problem.

Because it is possible to pass
an iterator to the wrong container. But I noticed that in standard
containers there is this kind of thing (like vector::erase).

Invoking erase with an iterator of another container is undefined behavior.

But what are the alternatives? If you pass an index instead, then
invoking erase with an index of another vector would only be defined
behavior from the vectors point of view as long as the index happens to
be within the bounds of the (wrong) vertor. But from the applications
point of view it is most likely undefined behavior in any case.


Marcel

 

[mike3]

I see nothing wrong with that. It is a common practice.
Iterators should by definition be cheap to copy. So passing them by
value is no problem.


Invoking erase with an iterator of another container is undefined behavior.

But what are the alternatives? If you pass an index instead, then
invoking erase with an index of another vector would only be defined
behavior from the vectors point of view as long as the index happens to
be within the bounds of the (wrong) vertor. But from the applications
point of view it is most likely undefined behavior in any case.

Marcel

Thanks for the answers. I still have one more question: how should the
container extract the information contained in the iterator to use it?
E.g. if the iterator wraps up an index, for example, and we want to
delete
the indexed object from the container, doesn't the container need
access
to the private index inside the iterator? Is it OK to use a "friend"
here?

 

[Juha Nieminen]

Is it OK to use a "friend" here?

Why wouldn't it be?

 

[mike3]

  Why wouldn't it be?

I've heard friends are "bad" or "evil". Or is this a case in which
it might actually be good?

 

[Dombo]

Op 29-Dec-11 11:08, mike3 schreef:

I've heard friends are "bad" or "evil". Or is this a case in which
it might actually be good?

Only friends may touch your private parts, so you better be selective
who you make friends with. However for closely related classes and
functions making them friends may be preferable over making members
public only for the sake of those closely related classes and functions.

 

[Juha Nieminen]

Not true; std::vector iterators *may be* invalidated upon push_back or
resize; std::vector iterators are *always* invalidated if the capacity
of the std::vector changes.

It's just that there's no way of knowing if an iterator got invalidated
using the iterator only. (And even with the vector, you would have to
compare the capacity before and after the insertion, which is cumbersome.)

 

[Juha Nieminen]

If you reserve() an appropriate capacity you can know in advance if
push_back() will invalidate any iterators or not.

But then you would have to make sure to not to exceed that capacity.

It's just easier to design your program so that it doesn't assume that
vector iterators have long lifetimes, if the vector might change during
the execution of the program. (It's different if eg. you initialize a
vector once, and then it doesn't change anymore after that.)