Re: iteration blues
Henk van Voorthuijsen wrote:
bob wrote:
So, I wrote this code for some particle effects:
package com.coolfone.particles;
import java.util.Iterator;
import java.util.Vector;
import javax.microedition.khronos.opengles.GL10;
public class FireManager {
static Vector<Particle> particles = new Vector<Particl=
e>();
... [snip]
public static void drawfire(GL10 gl) {
Iterator<Particle> i = particles.itera=
tor();
while (i.hasNext()) {
Particle p = i.next();
p.draw(gl);
}
}
}
I'm concerned about inefficiency in the burnfire function. Does
Why? What do your measurements tell you? What is not working because of t=
he time this method takes?
anyone know how to rewrite this quickly if particles was a linked
list? The main issue is that I'm not sure if removing items during
iteration messes up the iterator.
all Vectors should be LinkedLists, I think. Since you're only adding
to the end of the list or terating over it, performance shouldn't be
an issue.
BTW, while loops over an iterator are obsolete since Java 1.5 came
out.
Consider using the enhanced for loop:
public static void drawfire(GL10 gl) {
for ( Particle p: particles ) {
p.draw(gl);
}
}
No need to expose the iterator anymore...
That is not true. There are all kinds of scenarios that require one to exp=
ose the iterator. It looks like the OP's scenario, for one, requires him t=
o expose the iterator.
the issue is removal of items from the list as each is processed. If your =
algorithm is (pseudocoded):
for each item in collection
process item
delete item from collection
you will need the iterator. If your algorithm is:
for each item in collection
process items
empty the collection
then you will not need the iterator.
Talking in a single-threaded world here. I'm not going to delve into concu=
rrency issues yet.
--
Lew