Re: Iterators in Java and C++
On Apr 14, 1:54 am, chsal...@gmail.com wrote:
Overall, I usually prefer C++ iterators to Java style
iterators for subjective, aesthetic reasons. However, there
are times when I question the sanity of having two iterator
objects instead of one.
That is, of course, the crux of the problem. Requiring two
objects to implement a single instance of a specific concept,
with each object only containing part of the information.
Sam pointed out that Java iterators are much less efficient
constructs, (using virtual functions and frequent reallocation),
Sam's just our local troll. I wouldn't pay too much attention
to what he says. In practice, I've not found Java's iterators
to be excessively slow. In the end, however, it will depend a
lot on the VM or the compiler optimizer.
but the issue here I think is not so much the actual
implementation, but the interface. In other words, would it
be better to implement Java- style iterator constructs in C++?
Why not implement something better than either, like the GoF
iterators?
There are actually two issues involved, the iterator interface,
and whether it uses copy or reference semantics. With regards
to the first, it seems fairly clear from a design point of view
that requiring two iterators isn't really very clean, and cause
problems. The choice between copy and reference semantics,
however, is much less clear. There are significant use cases
for both (and the input iterator concept in the STL makes
allowances for this---an input iterator basically has, or is
allowed to have, reference semantics). My own current policy is
to implement copy semantics, using the GoF pattern, and adding
an isEquals() function if possible, then derive from a template
using the Barton & Nackman trick to provide the STL
interface---at best, however, a forward iterator. This seems to
work well in practice, most of the time; in cases where I need
reference semantics, I can always pass a reference.
(Note that reference semantics more or less impose an in order
traversal; copy semantics give the implementation much more
freedom. This probably isn't a critical point at present, but
once we start getting compilers capable of automatically
parallelizing loops, it could start making a significant
difference in performance.)
Especially, in a case where you have a rather complex iterator
object that has a lot of member variables, and so takes up a
lot more stack space than a simple pointer. Usually, the
"end" iterator object is only there so you can compare a
single member variable. The rest of the member variables in
the "end" iterator object are usually unused. While there's
probably not any measurable performance loss, the Java- style
interface would me more efficient in theory, because you
wouldn't have the extra "end" iterator with all the useless
member variables it stores.
This is really part of the copy vs reference semantic issue,
more than the interface issue. The STL supposes that copy is
cheap, and copies a lot. From a performance point of view, this
isn't always the right solution, but performance is rarely the
issue. Copy and reference have different semantics. Sometimes
one is more appropriate, and sometimes another. There is no
"right" answer.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34