Re: iterator and index
Mirek Fidler wrote:
G wrote:
for(size_t i=0;i!=vi.size();++i) //for(vector<int>::iterator
iter=vi.begin();iter!=vi.end();++i)
cout<<vi[i]<<endl; // cout<<*iter<<endl;
}
vector<int>::iterator x=vi.end();
for(vector<int>::iterator iter=vi.begin(); iter!=x;
++i)
will it take less time?
No, most likely not, but the same thing with vi.size() will.
It depends. My measurements (admittedly done a few years ago)
showed that hoisting the call to end() out of the loop did
measurably improve performance. Not be very much, however; I
certainly wouldn't worry about it unless the profiler said I had
to (and I wouldn't be surprised to get different results from
the measurements with a different compiler).
The reason is that vector is designed for iterators, therefore end() is
more optimal than size().
One of the goals of vector is that it can efficiently replace C
style arrays in most contexts. Indexing should be efficient.
You're also guaranteed that incrementing a size_t is efficient.
Incrementing an iterator generally means a function call.
Although again, a good optimizer will often make the point moot.
To be more specific, implementation usually uses begin/end pointers and
size has to be computed as (end - begin) / sizeof(T).
A good optimizer will almost certainly rewrite the loop to use a
stepped index, incrementing in fact sizeof(T) each time through
the loop, and comparing with (end - begin). Depending on the
contents of the loop, the compiler might even be able to figure
out that end and begin don't change, and generate exactly the
same code for both loops.
Off hand, what I'd typically expect is:
-- no or very little optimization: the loop with the index is
faster (because no function call for incrementing),
-- very good optimization: both loops generate exactly the same
code, and
-- medium optimization: the iterator version is probably
faster, because it can maintain the pointers (hidden in the
iterators) in registers. (To do this with the indexed
version, the compiler must determine that the pointers in
the vector object never change. Which typically requires
more analysis, since the vector object is typically visible
over a larger scope than the iterator.)
--
James Kanze (GABI Software) email:james.kanze@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
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]