   STL iterator specifics
  I don't have much experience with the C++ STL, so I'm incorporating it into one of my programs to learn. I'm using a vector to store a list of particles generated by a particle fountain. Each time the fountain's update function is called, the update function of each particle is called. If that function returns false (implying it is time for the particle to die), the particle should be removed from the vector:bool Fountain::update(const float& seconds){vector<Particle>::iterator i;i = particles.begin();while(!particles.empty() && i != particles.end()){if(!i->update(seconds))i = particles.erase(i);elsei++;}}Rather simple stuff. I declare an iterator and have it point to the first particle. As long as the vector is not empty and i is not pointing to the end of the vector, I call the update function to the particle i is presently pointing to. If that returns false, I remove the particle from the vector and assign i to what it returns (which should be an iterator to the particle just after the one that was removed). If not, I advance the iterator to the next particle.However, something is not quite right. When it comes time for the first particle to die, the entire list gets wiped out. That really shouldn't happen, as each particle has a 3 second lifespan, and new particles are constantly being created, meaning as the first one dies, the one most recently born should have 3 more seconds of life.In doing some tests, I can see that each particle does in fact have a unique life span, and that when the first one does, the call to particles.erase(i) is made many times (implying that the update function is returning false for each element). That's a bit odd, as the update function is based entirely on the particles' lifespan, and again they all seem to have unique values for their time alive.From an STL standpoint, is what I'm doing there what I think I'm doing there, or are my assumptions about the iterator or the erase function off? Perhaps I should switch to a list? I'm not entirely convinced that the problem lies with the use of the vector there, but that's my present suspicion. Does anyone see anything wrong with this? I'll supply more code as needed.   
  Strangely enough this same topic was recently discussed here. I don't know that the thread addresses the specific problem you mention, but it might be of interest to you nonetheless.   ;  Looking at your code a bit closer, the method you've chosen for managing the particles is probably not the most performant (see the other thread for further discussion). At first glance though, I'm not sure why your code isn't working. I don't think the call to empty() is necessary, but it shouldn't hurt, I don't think. (The problem is probably something obvious that I'm just missing, but it's also possible that the error is elsewhere in your code.)   ;  Thanks Jyk. It was good to read through that thread, gave me a few ideas.I'm thinking now my copy constructor might be to blame, though it is very simple:Particle::Particle(const Particle& p){pos = p.pos;vel = p.vel;acc = p.acc;rot = p.acc;off = p.off;offRot = p.offRot;friction = p.friction;life_span = p.life_span;time_left = p.time_left;alive = p.alive;}The variable time_left is what determines whether or not update passes or fails. Assuming erase shifts the elements of the vector down to fill in the erased space, I would assume this is what gets called for each member. The thing is, it doesn't get much simpler than time_left = p.time_left, and so the new time_left values of the particles should still get the right values.Still, switching things over to a list (who's behavior would differ in that it would simply re-link, rather than shift, I would imagine), appears to work properly. That's good enough for my program, but if anyone has any further insight as to why the vector version (and thus my copy constructor, I'd imagine) was in error, I would be very interested to know.Thanks again, Jyk!   ;  Still don't see what might have caused the particular problem you mentioned, but I did notice this copy-and-paste error:rot = p.acc;Also, from what you posted at least it looks like you could ditch your copy constructor and just use the default (which would eliminate future such errors). That is of course assuming that a shallow copy is appropriate, but that's likely to be the case for a particle class.   ;  A shallow copy is fine, though I was under the impression I had to define my own for whatever reason. Now that I think about it, though, I see no reason why the wouldnt do.Thanks again, Jyk!EDIT:Same problem using the default copy constructor and vectors, but fine with lists. The mystery continues, while I have fun with my oh-so-sexy, working, particle fountains.[Edited by - CyberSlag5k on June 4, 2006 3:53:55 PM];  Are you passing around any pointers to elements of the vector "particles"?   ;  Nope.   ;  This is weird. If the particular piece of code that handles the particles is not very big, just post the whole thing. The fact that lists work and vectors don't means that maybe there is still a small bug in your program somewhere.   ;  Could be, though honestly I'm not doing a whole lot of dynamic allocation. I have a dynamic matrix of floats for my map (which I'm very careful with), a couple of pointers for a couple of objects (less than 5), and that's about it. I only have 2 static arrays, one for standard key input and one for special key input. So as far as memory collisions go, I'd be pretty amazed if I have one.Still, ya never know. It could be something entirely different. It's not all that large, but I tore it apart somewhat getting these silly particle fountains working. I'm going to go through and clean it up a bit later tonight, I'll let you guys know if I find anything.Thanks again for all if your suggestions and help, guys!   