Iterator doubts, Decision on Iterator usage

[greg]

Hello all,
I havent used STL containers much, as I am used to MFC
containers/classes always
..The differences that I could see is iterators and algorithms.
The algorithms providing some basic functinaloties which are also
present in respective MFc container classes,
I wanted to know what is the main powers in Iterators ??
I have written some test programs,stl containers, using iterators,and
some stl algorithms,
I feel the code has been simplified especially when iterating, But I
wanted to know
how to pickup or decide a right iterator, I mean a forward iter,
Backward iterator etc....

This should help me in future to think about using STL instead of MFC
?


Thanks
Greg

 

[Victor Bazarov]

I havent used STL containers much, as I am used to MFC
[...]
This should help me in future to think about using STL instead of MFC
?

Get two books: "The C++ Standard Library" by Josuttis and
"Effective STL" by Meyers. Those should help you.

Iterators are special types with very convenient semantics
that allow algorithms to operate on the iterator's container
without knowing what it is. You can use the same 'sort' for
any container whose iterators are of random access kind. You
can use copy with any container (even a C++ array, for whom
a pointer is an iterator). And so on...

Victor

 

[Alan B]

Hello all,
I havent used STL containers much, as I am used to MFC
containers/classes always
.The differences that I could see is iterators and algorithms.
The algorithms providing some basic functinaloties which are also
present in respective MFc container classes,
I wanted to know what is the main powers in Iterators ??
I have written some test programs,stl containers, using iterators,and
some stl algorithms,
I feel the code has been simplified especially when iterating, But I
wanted to know
how to pickup or decide a right iterator, I mean a forward iter,
Backward iterator etc....

This should help me in future to think about using STL instead of MFC
?

One reason to consider STL over MFC, is portability. Using the STL container
classes should make porting your code to other platforms less painful.

Scott Meyers' book "Effective STL" may answer some of your questions. As
deciding forwards, or backwords iteration, It really depends on how you want
to traverse the container. You can use either type of iterator (in most case
they are bidirectional). However if you want to look at the container in
reverse order, and use operator++ to move backwards, use the reverse
iterator. If you want to look at the container from the start to finish,
using operator++ to move forwards, use the forwards iterator.

There shouldn't be a penalty for choosing one or the other, however when I
think about iterating, I start from the first element, and work my way to
the last by incrementing the iterator. When I want to go in reverse, I start
from the last element, and work my way backwards by decrementing the
iterator. Mostly because I think to readers of my code, it'll make more
sense, than using a reverse iterator, but calling operator++ to go
backwards.

HTH,

Alan

 

[vijay]

Thanks for the reply,
I have programmed using stl, But not too much
I could see iterator is a pointer to an element, in a container,
In that case, I can my self implement my own iterators , But only thing is
my iterator can be both incrmented and decremented, This should depend on
whether I have both ++ or -- overloaded, Bi-directional Iterator ,
Pls correct me if I am wrong,
I have see MSDN help files over iterators
Here is a brief text of the same
Msdn Text start----"
a.. OutIt -- An output iterator X can only have a value V stored indirectly
on it, after which it must be incremented before the next store, as in (*X++
= V), (*X = V, ++X), or (*X = V, X++).
a.. InIt -- An input iterator X can represent a singular value that
indicates end-of-sequence. If such an iterator does not compare equal to its
end-of-sequence value, it can have a value V accessed indirectly on it any
number of times, as in (V = *X). To progress to the next value, or
end-of-sequence, you increment it, as in ++X, X++, or (V = *X++). Once you
increment any copy of an input iterator, none of the other copies can safely
be compared, dereferenced, or incremented.
a.. FwdIt -- A forward iterator X can take the place of an output iterator
(for writing) or an input iterator (for reading). You can, however, read
(via V = *X) what you just wrote (via *X = V) through a forward iterator.
And you can make multiple copies of a forward iterator, each of which can be
dereferenced and incremented independently.
"
Msdn Text end----------
Can some body explain some kind of difference between above 3,
If I use a Bi directional Iterator, it would serve all the pourpses of
out,in, Fwd, Then why should I make a decision between iterators ????
Is there any over head using a Bi directrional Iterator,I meant to say,
performance,

My general feeling is that iterators would be most useful when coupled with
Algorithms ....
I would also try looking into books specified by above two people,,
Thanks
Vijay

 

[Victor Bazarov]

(e-mail address removed) (greg) wrote in message

There are a number of reasons why iterators are useful. Say you want
to sort only the first half of a vector. If sort was a member of the
class, you couldn't, but with iterators you can.

This is nonsense. If sort were a member, I could give it two
arguments: where to start and where to end. Just like we now
do with iterators. So, let's assume you didn't write that
paragraph...

Another reason is that you can write iterators for your own
collections which allows you to use the <algorithm>s in the
standard library.

That's the ticket!

A third reason is that you can write a single function taking a
pair iterators and have it work on all standard containers plus
any other container written that has iterators.

....which is another side of the same coin. Implementers of
the Standard Library write functions that can be used with
any iterators.

A fourth reason is that iterators provide a common notion of
"element not found", by returning the last iterator (the one
that doesn't point to an element). This is of course not new,
arrays worked the same but now the same notion can also be
used on linked lists.

I am not sure how this is special.

The often missed beauty of iterators is that they are very
similar to pointers in semantics. What pointers are to
arrays, iterators are to containers.

Victor

 

[vijay]

The reply by Mr. Kheul was very useful
Now I understan that InIt will not work on a container but rather in a input
sequence like from theuser,
But How will the ietrator incremented , I mean on ite incrementation which
memory location will it read as it is like a pointer ???
A code snippet will be mroe useful
Regards
Vijay

 

[Dietmar Kuehl]

The reply by Mr. Kheul was very useful

Assuming you std::reverse()d the middle of my name: it was the intend to be
useful. However...

Now I understan that InIt will not work on a container but rather in a input
sequence like from theuser,

.... this is not at all what I meant! An input iterator is simply used for
read-only sequences where it is not reasonable to provide multi-pass or
multi-position semantics. Typically, a container is capable to provide both
and it is thus reasonable to also provide additional capabilities. However,
I can imagine data structures which mutate while being accessed (splay-trees
come to mind although these don't fit the problem...) making eg. multi-pass
infeasible.

But How will the ietrator incremented , I mean on ite incrementation which
memory location will it read as it is like a pointer ???

Take a look eg. at 'std::istream_iterator<T>' (abbreviated as 'IsIt' below).
Essentially, this iterator internally stores a 'T' object and a pointer to a
stream. The basic operations work like this:

- the ctor and operator++() attempt to read a 'T' object:

IsIt::IsIt(): mStream(0) {} // to create a "past the end" iterator
IsIt::IsIt(std::istream& s): mStream(&s) { ++*this; }
IsIt:perator++() { *s >> mVal; return *this; }

- operator*() merely returns the internally stored value:

T const& IsIt:perator*() { return mVal; }

- operator==() checks whether both streams are OK or both are not OK:

bool IsIt:perator==(IsIt const& it) const {
return (mStream && *mStream) == (it.mStream && *it.mStream);
}

This assumes that 'IsIt' has two members:
- 'mStream' which is a pointer to an 'std::istream'
- 'mVal' which is a 'T' object

Actually, a setting like this is quite common for input iterators. Output
iterators are similar but don't have the comparision operator. Instead, they
typically implement some form of assignment operator to capture the mutation.
Of course, the above is hacked for this discussion. A real implementation
will probably deviate from the above excerpts.

A code snippet will be mroe useful

Will it? Why? Iterators are specified in much detail. Just fulfill their
contract and you're done.