tags:

views:

764

answers:

5

How is the implementation of Iterator in Java different from that in C++?

+6  A: 

C++ doesn't specify how iterators are implemented. It does however specify their interface and the minimal behaviour they must provide in order to work with other Standard Library components.

For example, for input iterators, the Standard specifies that an iterator must be dereferenceable via the * operator. It does not however specify how that operator is to be implemented.

anon
That's the whole point of operator overloading.
Malfist
Java doesn't specify either; Iterator<T> is an interface. I don't think there is any real way to answer the question other than this.
Michael Myers
The C++ library (the part formerly known as STL) is very precise about defining how the iterator concept should be implemented.
Tom Hawtin - tackline
@Tom - The C++ language is specified by the ISO standard, and I can assure you that there is mention in that document of how iterators should be implemented. Or perhaps you are using teh word "implemented" in some special sense?
anon
I'm using the word "implemented" in the dictionary sense, as it appears the questioner is doing. Your answer seems to be barking up a code monkey tree.
Tom Hawtin - tackline
It is usual in OO languages like Java and C++ to differentiate between interface and implementation. As the questioner used the latter term, I assmed that was what he was asking about.
anon
@Tom, however where does the C++ Standard say how iterator ops are implemented? It just says what operations are possible. It does explicitly say that for those requirements, the implementation is free to implement it as it wants, as-long-as the requirements are fulfilled (so, operators can be implemented both as members or free functions, for example). It's as far as that the standard even allows an implementation to use a raw pointer for vector<T!=bool>::iterator aswell as a class containing debugging informations and checked operations for ++, -- a.s.o
Johannes Schaub - litb
@litb: Tom means that the Iterator pattern is implemented in C++ as the iterator interface (well, the various iterator concepts, although he doesn't mention that). These interfaces are in turn implemented many times in code by libs and apps. Meanwhile the Iterator pattern is implemented in Java as the java.util.Iterator<E> interface, which in turn is implemented many times in code by libs and apps. The original question is either interesting or meaningless according to whether you allow "implement" to mean "design an interface in accordance with a pattern". Tom thinks yes, Neil no.
Steve Jessop
A: 

implementations are defined entirely by standard library vendors/JRE vendors in C++/Java respectively. They aree free to implement them however they want, as long as their behaviour ocnforms to the respective standards.

Visage
That's really a different application of the word implemented.
Tom Hawtin - tackline
+1  A: 

C++ iterators (STL) try to mimic pointer syntax as much as possible, through operator overloading.

The standard specification define the various iterator concepts (like forward, bidirectional, random access, input, output). Each concept should match a specific interface (e.g. ++ operator for forward iterator to go to the next element in sequence, -- for bidirectional, +, += for random access, etc).

Cătălin Pitiș
+7  A: 

In the current C++ (97) standard library (in particular the portion formerly known as STL) defines a form of iterators that are very close to C pointers (including arithmetic). As such they just point somewhere. To be useful, you generally need two pointers so that you can iterate between them. I understand C++0x introduces ranges which act more like Java iterators.

Java introduced the Iterator (and ListIterator) interface in 1.2, largely taking over from the more verbose Enumerable. Java has no pointer arithmetic, so there is no need to behave like a pointer. They have a hasNext method to see if they have go to the end, instead of requiring two iterators. The downside is that they are less flexible. The system requires methods as subList rather than iterating between two iterators are specific points in the containing list.

A general difference in style is that whereas C++ use "static polymorphism" through templates, Java uses interfaces and the common dynamic polymorphism.

The concept of iterators is to provide the glue to allow separation of "algorithm" (really control flow) and data container. Both approaches do that reasonably well. In ideal situations "normal" code should barely see iterators.

Tom Hawtin - tackline
I didn't think there would be a good answer to this question, but this is one. +1
Michael Myers
There is no such thing as the "C++ (97) standard library". The C++ standard, described in ISO 14882 appeared in 1998, and was updated in 2003. It nowhere defines how iterators are implemented, but does of course specify the interface they provide.
anon
It precisely defines how the *concept* of iterators are implement. Which appears to be what the question is about.
Tom Hawtin - tackline
OK, if that is the case, please provide the section number(s) in the Standard where these implementations are specified.
anon
I said the way the *concept* of iterators is implemented is defined. In the same way AWT 1.1 event model defines a way of implementing the observer concept.
Tom Hawtin - tackline
Sorry, in your comment on my answer above I don't see the word "concept "used anywhere. It is also not used in the sense you mean in the C++ Standard sections describing iterator, which I suspect you have not read.
anon
Why is it necessary to use the word "concept" when talking about a particular concept? Capital-I Iterator is a pattern/concept/idiom used in both the C++ standard library and the Java libraries.
Tom Hawtin - tackline
"Concept" in OO languages is a term with a techical meaning, along with "interface" and implementation", terms you seem strangely unfamiliar with.
anon
Words do indeed have multiple defintiions. They are clearly being used with normal dictionary definitions here.
Tom Hawtin - tackline
However, to implement a concept means to realize it, if my english is not all lost yet. The C++ standard doesn't dictate how an iterator is to be realized. It's going to be much looser with C++1x's conceot maps. You will be able to write code so normal integers can be used as input iterators, because there can be concept maps that teach the compiler how an integer can be dereferenced. C++ precisely defines the concept. But it doesn't precisely define how that concept should be implemented. That's the strength of generic programming.
Johannes Schaub - litb
However i sure see your point. The OP did use "implementation" in a way not familiar to me and possibly @neil, and you decided to go the same way as the OP. So as far as where my opinion is concerned, i'm with both of you. <3 :)
Johannes Schaub - litb
A: 

In C++, you see people passing around iterators all the time. C++ iterators "point" to a specific element of a container. You can dereference an iterator to get the element (and you can do this over and over). You can erase the element that an iterator refers to efficiently. You can also make copies of an iterator (either by assigning to another variable, or passing an iterator by value to a function) to keep track of multiple places at the same time. Iterators in C++ can become "invalidated" by certain operations on the container, depending on the container. When an iterator becomes invalidated (the rules of which might be complex), operations with the iterator have undefined behavior, and may (inconsistently) crash your program or return incorrect results; although in some data structures (e.g. std::list), iterators remain valid through most modifications of the container.

In Java, you don't see that kind of usage. An Iterator in Java points "between" two elements, rather than "at" an element. The only way you get elements with an iterator is to move it forwards to get the element you moved over. Of course that changes the state of the iterator, and you can't go back; unless you have a ListIterator in which case you can move both forwards and backwards (but it is still annoying to have to move forwards and backwards just to remain still). You can't copy an iterator, because the interface does not expose a public copy method; so for example, you can't just pass a marker of a specific location to a function, without giving that function a reference to the same iterator that you have, and thereby allowing them to change the state of your iterator. In Java, an iterator will be invalidated (at least in the standard containers) by any modification of the container except through the iterator's own add() or remove() methods, which is overly conservative (e.g. most modifications on a LinkedList should not affect an iterator). When you try to use an invalidated iterator, it raises ConcurrentModificationException (confusingly named because it has nothing to do with Concurrency) instead of possibly causing undefined behavior, which is good.

newacct