Re: Andrei's "iterators must go" presentation
cjhopman wrote:
On May 15, 2:59 pm, "Thomas Beckmann" <ka6552-...@online.de> wrote:
Repeat your test reversing the sections in main, do your range test then the
iterator test. Chances are you get different results due to memory
allocation overhead in the runtime, cache misses, etc. Notice, the second
run does not change any data which the hardware might take advantage of.
Reversing the sections in main makes no difference, the timing is
still the same.
Notice, the second run does the same thing as the first one on a
different data structure.
A design issue is that range::next() mixes up advancing and querying
operations. Now, for supporting const-correct code you will need an explicit
has_next() function.
You want the advancing and querying operations to be done together,
otherwise you often end up doing the query twice (also, "advancing"
and "reaching the end" are very much related things). You could add an
additional querying operation, if you wanted.
This is an interesting point. My first design defined a different
interface for input ranges versus forward ranges. Input ranges were:
template <class T> struct InputRange
{
bool empty() const;
T popNext();
}
whereas forward ranges were (and are):
template <class T> struct ForwardRange
{
bool empty() const;
T& front();
void popFront();
}
I think one can pursue such a design, but I found it difficult to write
code that works efficiently with forward ranges adapted to input ranges.
(Notice return-by-value from popNext). To simplify everybody's life, I
decided to require input ranges to cache the last element fetched (just
like the STL does). Things seem to work pretty well.
Andrei
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]